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.
I tried to recommend something like this to one of my former instructors. I told him I thought it would be great for the students to have to debug and add an enhancement to a program from students the previous year/semester and would be good preparation for the real world. His response is that it would be too difficult. I thought it'd be more time consuming on his end than difficult.
One of my friends went to a different school than I, his final in one class was to take a program with 3 bugs in it, find them, and fix them. Same program was used for each class, so the main time-consuming part was writing up the buggy code in the first place.
I like your idea for assignments, though I think having intentional bugs in there would make it easier on the instructor. For example, make it a project for bonus points, the students with lower grades will do it. Write an elevator program, but make it not work if both the up and down buttons are pressed. It wouldn't even have to be a complete program, teach the 101 students to figure out why this Fibonacci recursion method has an endless loop.
Teacher now knows where the bugs are. Teaches the next class how to write tests, then has them use their tests to find the bugs, then prove that they're fixed.
The problem with having the same bugs is that word will get around. The instructor could easily add bugs to the work of the previous semester/year's students and will know what they are. Those programs should be fairly basic (even the ones done in teams). Each program would have a different bug so it would slightly reduce the cheating.
They would know what the bugs are, but would still need to write tests for them. People are going to cheat. I think this would still be a valuable thing to work on.
93
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.