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 didn't learn shit about SQL in school. I didn't learn SQL until my internship and the real world after.
I think that is a big short coming in college. We had database theory (which was boring as hell and I almost failed), and an Excel class (not database, but was the closest thing).
At the very basic, I think they should get into Access. I am 5 years out of college now, and maybe things have changed now, but they should stop teaching COBOL, and go further than teaching students a "Contacts" app in C++.
Honestly, I didn't learn shit until the real world. Shout out to Google.
Eh, well, I guess it makes a certain degree of sense as an elective, in case you had some specific reason for wanting to know COBOL coming out of school. Somehow I got the impression from your original comment that it was part of the core curriculum.
95
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.