Such keys make it possible to relate the tables to one another, so we can, for example, find the customer information given a key value in the order table. A foreign key is a key used to link two tables together. Typically you take the primary key field from one table (customer) and insert it into the other table (order) where it becomes a foreign key (it remains a primary key in the original (customer) table). This type of structure is called a relational database: we have multiple tables that connect to one another via keys.
It's really jarring to see such wrongness published under the banner of "Google Code University." I've come to terms with the fact that in the minds of most web/MySQL programmers the term "relational database" means graph/network database. But I still don't expect to see it published by the denizens of a top engineering firm that hires only the best and brightest.
If you look closely enough, they didn't say anything incorrect. The name "relational database" is the correct name for the structure they describe. Their description might not be precise, but it's accurate.
Yes, the common misconception is that the word "relational" has to do with relationships between the tables, where in fact it comes from the mathematical concept of relations. However, the text you quoted doesn't claim anywhere that the word "relational" has to do with relationships between tables.
the text you quoted doesn't claim anywhere that the word "relational" has to do with relationships between tables
Hmm, I disagree.
This type of structure is called a relational database: we have multiple tables that connect to one another via keys
The emphasis here is on the connections rather than the tables. Why say "multiple tables"?
In writing for beginners the author should just say something truthy like: "A relational database is a database where all data is stored in values of an algebraic data type called a 'relation'. SQL uses the word 'table' instead of 'relation', but the two words mean roughly the same thing."
This is why I used the word "claim". The sentence you quoted can be construed to imply that relational databases are relational because of the relationships between tables, but it certainly does not claim that.
I'm not merely nitpicking here, I'm trying to explain that what you perceive as the author's mistake is, in fact, your interpretation. I do, however, completely agree with you in that the text would have been better if the author phrased it in such a way as to deliberately avoid the possibility of that particular interpretation.
In writing for beginners the author should just say something truthy like: "A relational database is a database where all data is stored in values of an algebraic data type called a 'relation'. SQL uses the word 'table' instead of 'relation', but the two words mean roughly the same thing."
What you've written here is worse, for the simple reason it is now semantically wrong instead of just syntactically wrong in the use of the word relational.
As an example, all relational databases that the average reader can be expected to have heard of use bags(multisets) instead of sets, so they in fact don't store data in relations.
Language gets polluted over time. Trying to force a technically correct but obsolete meaning is not helpful to anyone.
I know what a relation is, but that is my understanding of what a "relational database" is in standard practice. What do you think relational database actually means?
In order to combat this madness it should be spelled out to all beginners that "table" and "relation" mean basically the same thing. And that "relation" has nothing to do with "links" or "relationships" between tables or between entities.
This big misconception comes from Raymond Chen's idea of E/R modeling.
That's the fundamental idea. But there's also a slightly more advanced understanding. That is that your tables/relations can't contain pointers. If you put pointers in your relations then you've created a graph/network database.
Think about encapsulating an array inside an object class and exposing "push" and "pop" methods. Wouldn't you agree that when you use an object of that class you're using a stack, not an array? Because the interface is what matters, not the implementation. The situation with pointers in your tables is slightly more complex, but roughly analogous.
Unfortunately, this use of the word relation, while I agree correct, has fallen out of favour, I think because it is confusingly similar to relationship, and because table is used everywhere instead (except academia.)
I'm not sure I understand what you mean about pointers though. I'd agree that if you have literal memory pointers, then you have an object database or a graph/network database. But entries in a relation based on values of candidate keys of another relation (that is, foreign keys) fit exactly within the relational algebra (natural join).
I don't see how information hiding in OO is analogous to not calling a database relational.
I'm not sure I understand what you mean about pointers though.
I'm talking about the practice, widespread in MySQL world, of all tables having a primary key of auto-increment integer.
There's nothing wrong, per se, with the example in the document as both Customer and Order are cases where an auto-integer is an appropriate primary key.
But I do think the reader could easily get the wrong idea, since the example consists of only those 2 tables.
Edit: Not that there's anything wrong with the practice. Just that your database is no longer a relational database. Knowing that fact and understanding why is, I think, a useful and educational thing for a student to understand.
this use of the word relation has fallen out of favour
Do you think that's true everywhere or just in web development world / MySQL world? I'd always guessed that, say, Oracle professionals know and understand the difference between "Chen--E/R model" and "Codd--relational database". But I'm not part of that world so I don't really know for certain.
I found myself in a startup last year with web applications to write and no idea how to write them; a colleague pointed me to GCU. I didn't find it very useful at the time, but in retrospect this was simply because I don't have the attention span to watch videos and the textual content is pretty basic and limited.
Dear web sites comprised of videos of lectures: videos of lectures are not "courses" or "universities". In fact, the lecture is arguably the least valuable part of a course or a university. Stop degrading the value of online learning by pretending you're a university. Thanks.
It's the internet. I won't stop you. But, honestly, are you really calling this online resource of educational videos a bad thing....because they dared call it a university?!
No one is saying, hey future students, good news! You don't need to go to university anymore because of code.google.com/edu!
Cool, didn't know there was so much stuff on distributed systems on there. (I have like 100h of Videos I want to watch Interduction to Algorithems, Multicore stuff, compiler courses and much more)
The following link, http://code.google.com/edu/languages/index.html#_java_racede..., is even more fascinating. It shows how to detect race conditions in concurrent Java programs. What does it use? JChord? What is JChord built on? Datalog implemented via Binary Decision Diagrams!
I've queried Google for an old submission of GCU on HN, and the top comment of the first found submission[0] (which is 250 days old) is by you complaining that GCU has been submitted many times before. What a coincidence :)
It may sound alien to you because I should've used "I've done a Google search" rather than "I've queried Google". In other news, English is not my native language :)
Thanks, but there's nothing wrong with my memory. That only puts a fine point on my comment: how many times does GCU have to be submitted before everyone here "gets it"?
Someone answered that question in the old post too by saying that every 6 months doesn't hurt. People will stop upvoting if they think it's old news. Lots of stories get resubmitted on HN. The audience is probably growing. Lots of new people weren't here 250 days ago?
It wasn't meant to be a snarky comment; sorry if it came over like one.
searchyc.com[0] yields a lot of results, so you're definitely right with your statement.
I think we have to take into account that the number of HN users has probably grown quite a lot during the last year or two, so a link that you already know because you saw it on the frontpage may be new for the one or other user. Hence, I wouldn't be surprised if we'll see more dupe links of this kind on the frontpage.
Nah, I got your meaning. FWIW, I love GCU and have consumed a number of those videos. It's nothing against GOOG or GCU; it's probably that I've been here too long...
Such keys make it possible to relate the tables to one another, so we can, for example, find the customer information given a key value in the order table. A foreign key is a key used to link two tables together. Typically you take the primary key field from one table (customer) and insert it into the other table (order) where it becomes a foreign key (it remains a primary key in the original (customer) table). This type of structure is called a relational database: we have multiple tables that connect to one another via keys.
It's really jarring to see such wrongness published under the banner of "Google Code University." I've come to terms with the fact that in the minds of most web/MySQL programmers the term "relational database" means graph/network database. But I still don't expect to see it published by the denizens of a top engineering firm that hires only the best and brightest.