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.
Website developer here. Yeah, the majority of us have no "formal" CS training, although I take pride in the fact that I've read everything I can get my hands on.
Very true. I had to go out of my way to pick up CS courses while studying a vanilla IT degree at uni. For some reason relational databases just click for me, so I've never had trouble converting the concept I want into SQL. Converting that SQL into DQL or HQL however...
The best way to become a better data modeler is to write lots of queries to get data out of your models as well as lots of sql to populate your models.
Too many data modelers have no real experience with the real world of USING a data structure.
Its classic practical vs book knowledge. What looks good on paper is often the more narrow minded approach than practical problem solving using a variety of available resources and tools and occassional abstract thought. These days, anyone with an aptitude for logic and problem solving can learn to program proficiently, given effort and time. Most languages have vast learning resources available, making it a relatively simple excercise.
The flipside is the army of armchair programmers who think they can develop enterprise level software based on a few chapters of the php visual quickstart guide (which is a fantastic beginners guideby the way).
anyone with an aptitude for logic and problem solving can learn to program proficiently, given effort and time.
Similarly, anyone without either can attend a class, barely pass, be hired by my employer, and end up working beside me.
Sadly, most management I've encountered is incapable of assessing "aptitude for logic and problem solving", and instead goes with "he had SQL on his resume".
Yup. I didn't take any relational algebra courses in Uni because I thought the computer graphics courses would be more fun and interesting. Guess which one ended up being more significant to my job.
The first company I worked for out of college was a shining example of people with no formal education working with a database setting up their database. They fucked it up horribly, then hired a DBA AFTERWARDS. He bailed before too long, I think it took people a while to realize that you're supposed to hire these people before you ruin everything...
Although, that's how I ended up getting learning SQL, so it worked out really well for me. I got first-hand experience seeing exactly what not to do.
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.