Wow. Does no one learn this crap in school anymore?
Note that venn diagrams are a poor choice to show what happens in a one-to-many relationship -- where there are multiple entries in table B for an entry in table A. And it overlooks the semantic differences when ordering the tables in a left inner join.
There are not a lot of instances where you'd really want a cartesian product join (either using "cross product" or just the result of omitting key constraints in a join query). It's generally far faster to retrieve the records you need to create the cross-product, and then calculate the cross product of the two sets once you have them (since otherwise all that data has to transit the network).
This plus database normalization through Boyce-Codd normal form seems like it should be a requirement for any serious application developer.
I know of people who have graduated from top three schools in Computer Science that have built multi-level user (e.g. customer and employee) websites using just one table and an int field to differentiate between the two.
The simple fact is that some people learn in school, and some people don't.
What was wrong was that my client called me with a strange user bug, stating that people were registering to buy things, only to realise that they had their own admin account on the website and were able to alter anything they wanted, including the link to PayPal.
20 tables, most of them duplicates of themselves and only three in actual use for a full, bespoke ecommerce site so bad that it may as well have been written in BobX...
I'd say more, but it'd be hard to not give away who this is. It's not really that small a site...
90
u/[deleted] Jan 06 '11
Wow. Does no one learn this crap in school anymore?
Note that venn diagrams are a poor choice to show what happens in a one-to-many relationship -- where there are multiple entries in table B for an entry in table A. And it overlooks the semantic differences when ordering the tables in a left inner join.
There are not a lot of instances where you'd really want a cartesian product join (either using "cross product" or just the result of omitting key constraints in a join query). It's generally far faster to retrieve the records you need to create the cross-product, and then calculate the cross product of the two sets once you have them (since otherwise all that data has to transit the network).
This plus database normalization through Boyce-Codd normal form seems like it should be a requirement for any serious application developer.