Come for the quick hacks, stay for the epiphanies. | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Now right off the bat, if you know the rules of normalization you know these tables are not properly designed. However, for the sake of simplicity, bear with me.
If you have improperly-designed tables, then you will have improperly-designed queries to deal with the improperly-designed tables. Garbage In, Garbage Out. That said ... Your queries were improperly designed. You're conflating two questions into one query, so you have a hacked-up query (on top of improperly-designed tables). Much better is (written for MySQL 4.1+, though it will work on Oracle8+ and PG):
Note the use of a UNION to join two disjoint concepts. There is absolutely no reason to attempt to shoehorn this problem into one query when it's really two separate questions. Plus, the UNION will remove duplicates for you. Still relational theory. As for your rants ... I've been following them with some ill-taste in my mouth. Yes, you have had issues with databases (who hasn't?). However, you must realize something - you have a very public profile in the Perl community, which is completely deserved. Please do not use this profile to spread FUD about databases. RDBMS vendors may not be ivory-tower about their engines following relational theory, but neither do your examples. Your entire post was a straw-man with a poorly-concealed axe to grind. Now, if you were to provide something in at least 3NF that demonstrates your point about the lack of relational theory, then I'll be glad to learn from you. But, don't start out with something that's not even 1NF, conclude that relational theory is completely ignored by RDBMS vendors, and expect to not be taken to task about it. As for NULLs, they were a mistake in the initial SQL spec that, for historical reasons, will never be removed until some enterprising soul goes ahead and builds an extension to a OSS RDBMS that doesn't have them. I use them because the alternative is a performance penalty that my clients won't pay me to suffer. (For the uninitiated, a NULL column demonstrates a denormalization in your schema that should be normalized out into some options table. No-one does this because the performance penalty is prohibitive.) My criteria for good software:
In reply to Re: (OT) Why SQL Sucks (with a little Perl to fix it)
by dragonchild
|
|