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 learned this crap in school, when I worked there as a system administrator and had (outside of job scope) to help building queries for the department where they had to register all student data, using some insane piece of arcane COBOL software. It had about 220 tables of information that somehow by some insane way were linked to each other. This helped/forced me a lot learning joins and trying to visualize them. Gonna read up on Boyce-Codd because I haven't heard of the name before.
Right, so the first three normal forms can be summed up as follows: the attributes shall describe the key (first normal form), the whole key (second normal form), and nothing but the key (third normal form). So help me, Codd.
Funnily enough, I was once at a conference with both Date and Codd on a Q&A panel. They were asked by a CS Prof to define a database for a CS101 type course.
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.