Hacker News Reader

Comment by davidmathers | Hacker News Reader

From Introduction to Databases and MySQL:

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.

View on HN

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.

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.

> It's really jarring to see such wrongness

Codd help you

Reply on news.ycombinator.com