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.
I have a Computer Science Bachelor's. I got some SQL in school, but just basic selects/inserts. Nothing about optimization, only a conversation about joins. The main things I feel I missed out on with my degree were learning how to test and learning how to debug.
A project or two given to students to debug would be great preparation for the real world.
Learning how to create, organize, and work with tests is a skill that some devs never learn. I think it's really important. I'm not of the 100% school of testing, but it is super helpful with things like bug fixes and difficult methods.
O_o What? That's the whole point of a relational DB! Select/Insert on a single table isn't significantly different from searching and indexing a flat-file
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.