Love this interview, thanks for getting it out there for people to see again.
As for Date, he is a gem:
"Thank you for saying my writing style is “coherent”! But I think I can explain that, too. The truth is, I’m a rather slow learner. As a consequence, I think I can be a good teacher, because I can identify places where students are likely to have trouble."
Good observation. The ability to understand why someone else doesn't understand something and tailor an explanation that explains it in a way that clicks for them, is a rare and valuable gift among teachers.
Nice. Here are two passages that remind me of "history repeats itself".
> Looking back it seems such a simple idea to replace the hierarchical structures used to build databases with tables of rows and columns
> First of all, XML structures are fundamentally hierarchic; thus, all of the intrinsic difficulties with hierarchies that we experienced all those years ago-with IBM’s IMS product in particular-are rearing their ugly head again.
What I mean: the relational model has replaced existing hierarchical models. Isn't that proof by practice that the underlying mathematical model (set theory, predicate logic) is extraordinarily well suited to cover data structuring and information modeling in computer science. And, yes, hierarchies are also first-class citizens in relational models and can scale beautiful.
Even the developments, yes, "hypes" of recent years and decades such as NoSQL or knowledge graphs and graph databases have not fundamentally shaken this, but we are increasingly seeing a return to the proven relational model. Hence "history repeating".
> Isn't that proof by practice that the underlying mathematical model...
Maybe. Maybe not. The only practical example we keep seeing is implementations centred around SQL which, while loosely based on the relational model, notably does not have relations. Without relations – the idea that sits at the very core of the relational model – you don't technically have a relational database (even if we colloquially call it as such).
So while, in theory, the relational model should work just as well, practice hasn't attempted to prove that at scale. Not since Postgres was first created has anyone really even tried to implement the relational model, and Postgres soon gave up on the idea and moved to SQL too. It may be that tables are actually better for practical use and that the relational model would fall down flat if we ever gave it a serious go.
There definitely have been people who have implemented a more pure relational model (e.g. https://docs.relational.ai/rel) -- and at scale, too. There's just so much force and legacy behind SQL that it is pretty much impossible to do well in the industry without it.
But the relational model works and has been proven, independent of SQL.
Perhaps one should say that SQL "does not enforce relations". One can create systems that enforce uniqueness throughout and avoid nulls. My recollection is that Peoplesoft was one such--it used single spaces where some might have used nulls, and the tables had unique indexes defined on them. But it has been many years since I dealt with it.
By the same token, would you say that C doesn't enforce message passing? The Objective-C runtime proves that you can create C systems that use message passing – but certainly it is not enforced.
I think most people would say that C doesn't have message passing. Being able to use the facilities provided by the language ecosystem to build message passing / relations on top is at another level.
I think maybe you are confusing SQL's view of the model with the underlying mathematical Relational Model? A Table is a superset of a Relation. As Date mentions in the interview you can have QBE/ISBL be a better mapping to the underlying mathematical model.
Subset. You can build relations on top of tables, but not tables on top of relations. SQL falls short of the mathematical model. As it pertains to the topic at hand, whether or not that is significant is not something we have tried very hard to prove in practice.
Of course you can; it is in the very definition of the Table which is a manifestation of a Relation. Relationships (which can also be mathematical Relations) across Tables/Views are a different thing.
> hence it being a subset.
No, all Relations are Tables but not all Tables are Relations because of ordering, duplicates, nulls.
> Of course you can; it is in the very definition of the Table which is a manifestation of a Relation.
You said multiple relations earlier, which is what the comment was in reply to. Why the fliply-flopping?
> Relationships
Relation, not relations, not relationships. The struggle is real.
> all Relations are Tables
Yes, that's right, a relation is a table with additional constraints – a superset. Although not a strict superset as it does not carry ordering forward.
You seem to be confused between the mathematical definition of a Relation and the English usage of the word "Relation".
> You said multiple relations earlier, which is what the comment was in reply to. Why the fliply-flopping?
Read my definition above again; I said "multiple sets" and NOT "multiple relations" which is a very different thing. You understood it wrong.
> Relation, not relations, not relationships. The struggle is real.
Only for you. I have been very clear in the usage of my terms above. A Table encodes a Relation. Additionally, when you do a JOIN across Tables you are manifesting a "Relationship" (English usage) which may/may not result in a Mathematical Relation.
> a relation is a table with additional constraints – a superset.
No, If there are additional constraints on set A than on set B then A cannot be a superset of B but a subset.
As for Date, he is a gem:
"Thank you for saying my writing style is “coherent”! But I think I can explain that, too. The truth is, I’m a rather slow learner. As a consequence, I think I can be a good teacher, because I can identify places where students are likely to have trouble."
I have learned so much from him.