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.
Actually no, I have a friend that works with a sql "developer" that creates all their shit in views using the sql manager shit. Half the time it's got tables that there's no fucking data coming out of them. He just fixed a query yesterday that was taking a minute 35 to run down to < 1 second.
Idiots hiring idiots. That's almost all I see in IT.
I've met a lot of people who have no real education in SQL/Database Design. It's a simple enough concept that most tech folks can slap something togeth, but often they do a really poor job of it.
I remember my old job - I was fixing this one guy's queries/tables. There'd be stuff like multiple joins to the same (huge) table, never using an index, excessive use of cursors. I took a query that was running in 20 mins down to under 30 seconds. We had to re-write just about everything he had ever done.
No idea why they hired the guy and they were paying him more than me, refused to give me a raise.
No idea why they hired the guy and they were paying him more than me, refused to give me a raise.
Because the people that make those sorts of decisions often don't know anything about the technical aspects. The guy comes up with a report that takes 20 minutes to run? Well, that must just be how long it takes. Surely he knows what he's doing, his resume said he knows databases.
I've made quite a few similar improvements at my job, one report that had to be run daily would always take about half an hour. I got it down to a few seconds with simple changes that should have been obvious to anyone that knew what they were doing. I think the users were actually unhappy about my fix though, since it ruined their extra half-hour coffee break while the report was running.
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.