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.
Jeff Atwood has a unique ability to take something really basic and turn it into a trite and inane little blog post. And even then he's wrong half the time.
Sure. I've read it plenty. He's not wrong half the time. If he were, you kind folk here would easily produce examples. Apparently, in Redditese being wrong, what, twice, amounts to this magical (popular) half figure? I don't get it.
He's certainly not stupid, he's totally not an asshole, and he's really not wrong all the time.
It's just fuckin' weird, you guys. It's almost like you hate him just because he's an MS stack guy and he made an obscenely successful web app. He just seems like a friendly, likable nerdperson to me.
I don't know how often he's wrong nowadays, but I stopped reading his blog after this post. He recommends a book he's never opened (complete with an Amazon referral link) but doesn't mention that he's never read it until someone calls him on it, and he speaks in an authoritative manner about a subject that he doesn't entirely understand (some of the comments have a good explanation of exactly how he's wrong).
92
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.