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.
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.