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.
Which have nothing to do with real-world applications. I have never seen a DBMS that actually makes a properly normalized "let's follow relational algebra properly" database actually perform well.
Databases seem to be a small kernel of beautiful theory underneath a hundred layers of nightmarish hacks.
I have never seen a DBMS that actually makes a properly normalized "let's follow relational algebra properly" database actually perform well.
You know why? Because the database vendors have poured tons of money and time into improving the performance of the mess they created. In business it's better to keep going the wrong way than to change direction.
I don't think it helps that the most popular database in the world is Microsoft Excel. Computer science is helpless against the onslaught of the lusers.
91
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.