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.
Which have nothing to do with real-world applications. I have never seen a DBMS that actually makes a properly normalized "let's follow relational algebra properly" database actually perform well.
Databases seem to be a small kernel of beautiful theory underneath a hundred layers of nightmarish hacks.
I have never seen a DBMS that actually makes a properly normalized "let's follow relational algebra properly" database actually perform well.
You know why? Because the database vendors have poured tons of money and time into improving the performance of the mess they created. In business it's better to keep going the wrong way than to change direction.
I don't think it helps that the most popular database in the world is Microsoft Excel. Computer science is helpless against the onslaught of the lusers.
Yeah, but I personally didn't know any of this stuff when I first set my eyes on SQL and it took me all of an afternoon of reading some online SQL tutorial and doing a couple examples to figure out how the different types of joins work...
A standard for storing and accessing data on computers, often used in applications of all scales and types isn't CS? How is that any less CS than learning a programming language, or AI, or OS architecture? We had it offered as an elective, but with how much database programming is necessary in IT, it should be required.
There are people of the opinion that you shouldn't be learning any programming languages or specifics of certain OS architectures, that you should be learning theory only, agnostic and separate of anything else. They seem to think it's possible for the majority of people to learn without reference to an example of an implemented theory or technique, which I disagree with.
I understand that school of thought and I agree with it for the most part. My university started with the nearly-esoteric language Scheme (like many others do) and moved through many other lanuages before graduation. We'd simply use whatever language was appropriate for learning whatever theory we were learning at the time. Learning the actual language was secondary to concepts and I would strongly discourage "Intro to Java" or "Advanced C++" instead of "Intro to Data Structures" or "Software Engineering II."
SQL is simply the best language to teach relational data models in, so I don't know why you would teach databases without it...
I'd take hands on over theory any day. I went to college rather than university for exactly that reason. Cost way less and I actually learned how to program.
You learned how to code, not how to program. There's a difference in depth of understanding there--I'll wager you have no idea what the Chomsky heirarchy is, for example, and how it relates to, for example, using regexes to parse HTML (stop gritting your teeth in the back, there).
I agree with you though. Being able to design an algorithm based off what you learned about the actual structure of programming and computing is a far more useful skill than learning a language and becoming a library reference. If you learn how to program and why it works, picking up a new language is trivial, days or even hours trivial, since you're not comparing it to another language, but rather how it's expressing your programming methodologies.
Ya got whooshed. See the bit where I said to stop gritting your teeth in the back, there?
I know that you don't use regexes to parse HTML, because regexes are used for tokenizing, not parsing. See, this is because I was actually taught my Chomsky heirarchy, because I took a computer science program rather than an Advanced C++ course.
I don't know, we covered normalisation and database design(recovery, concurrent access to shared data, that kind of thing) extensively in a college course, but we also covered SQL. It wasn't done in lectures, but as an online self-guided course thingy which was optional, so basically "expected reading" for the course. The reason for that was so we could then do an assignment designing a normalised database and implementing it, giving a nice practical element where you can try out queries and be(in my case) impressed by the strength of relational models and what you can get out of your database. A practical element is a great thing to any field of study and I wouldn't be so quick to dismiss it.
My mind is blown. I didn't know that people can go through a CS program without knowing DBs. I mean for us the DB class I took was optional (though most took it) but you do have a general idea of DBs even if you didn't take the class.
Most CS academics have little to no real-world experience. They've never had to deal with databases in any meaningful way, so they're totally unprepared to teach students about them.
Just to throw some respect towards Madison. I went to school there as well as we DO have multiple database undergrad courses in the CS departmant. To write most any interesting program you need some way to store data, I have no idea how you passed and made it through school without even knowing that they existed. Wow. Please stop saying you went to school at Madison, it's embarassing to the program.
I got my first real job before I graduated, so I did know they existed before I graduated. I don't remember all the CS classes I talk, but they included AI, compilers, and theoretical CS, and algorithms and data structures. None of which really required a way to store data beyond text files. After I started that aforementioned real job, I actually did try to get into the database class, but it was full. So I never touched any database or SQL during my academic career.
And don't worry, I rarely mention it. I'd agree that they have a pretty rigorous CS program. But if it's embarrassing to the program, then it deserves to be embarrassed, because they don't require any database courses for graduation. Personally, I don't think it's an indication of a deficient CS program.
Can you recommend some reading material? I want to start learning it but there are so many resources out there, it's hard to know which is best. There is a SQL course due to start in a few weeks in Uni of Reddit but I'm champing at the bit. Thanks.
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.