4 ms·

In first order predicate logic with an n-ary relation, attributes are columns and tuples are rows aka a table and what Codd used to justify it. The typical nor

In first order predicate logic with an n-ary relation, attributes are columns and tuples are rows aka a table and what Codd used to justify it. The typical normalization let's say in a star schema is viewable as a least fixed point. FO+LFP=P It is similar to what Codd called adjacency lists, which luckily died in the 80s, because they conflicted with real adjacency lists. recursive CTEs add transitive closure, which when added to FO gets you to L or NL, I forget which . Still it doesn't matter, the relational part of the relational model is attributes or column names...it is equivalent.

9rx 1y ago
> the relational part of the relational model is attributes or column names The relational part is defined, most importantly, by the set. That was key to Codd's model, and the source of his primary criticism of SQL. But his ideas went out of fashion long ago. Postgres, pre-1995, was the last time we saw a relational database anyone heard of. Sure, there have been some esoteric attempts more recently to revive the concept, but they never went anywhere. For all intents and purposes the relational model is dead. We live in a tablational world now. > it is equivalent. It is not, though. In fact, I posit that lists/multisets are easier to reason about, at least where one doesn't have a strong mathematical understanding (i.e. the layman), and that is why SQL "won". A list, if carefully constrained, can represent a set — which is maybe what you are struggling to suggest — but that does not make it a set.
- nyrikki 1y ago
  Can you provide any specific situation where the following does not hold? Especially if I add the constraint that rows have to be unique? Relations=Tables Rows=Tuples Columns=Attributes I think we may be from different schools of set theory, where I am from the more abstract direction, where set membership, inclusion and equality are separate concepts and don't need to be decided on to define a relation. Not that my view is better just different. I just happened to come through the {{foo},{foo}}=={{foo}} school.
  - 9rx 1y ago
    > Especially if I add the constraint that rows have to be unique?; Relations=Tables This is kind of like saying that a dynamically-typed programming language is statically-typed because you can add tests to enforce the same constraints as what static typing enables. There is a lot of truth in that statement, but you completely fail to capture the differences in calling said language statically-typed. And, sure, for a silly comment on HN, who cares, right? But on the other hand, what are you gaining by obscuring the differences? It is not like said programming language is somehow better because you call it statically-typed. It is still the same language no matter what you call it. SQL does not follow the relational model, as it was proposed by Codd. And that's okay. Arguably it is better because of it. Why not call it what it is? > Not that my view is better just different. Of course you can view things however your little heart desires. You can even see what I call a chicken as being a relational database if that is what floats your boat. But we are not talking about your view, we are talking about Codd's view. Every single comment that preceded this was clearly about Codd's take, to the point that you even linked to some of his work for us to engross in his thoughts. And we know very well how Codd felt about tables. He wrote about everything he thought was wrong with SQL at length.
    - nyrikki 1y ago
      No, you are confusing convention and simplifications for convenience for fundamental properties.. What is generally considered Standard set theory today is typically ZF(C), which can be viewed and was intentionally developed as what is not called a "material set theory" or sometimes a "membership based set theory" In ZF(C), sets are characterized only by the binary “∈” operation and propositional equality of sets. It is actually the less common schools like the Elementary Theory of the Category of Sets (ETCS), where individual elements have no identity and must be unique. There are well documented disagreements between Zermelo and Frege vs Cantor and Lawvere, was the former was for membership and the later were against it. With ∈ or "is a member of" both of the following hold: Given a set A={1,2,3,4}; 3 ∈ A Given a set A={1,1,2,2,3,3,4,4}; 3 ∈ A There is value in defining things like multisets/bags and accessing concepts like multiplicity, but you could use a function you defined for a multiset and discard that information and it would fit the axioms of ZF. In computer science and databases, this is less than just a trivial factoid depending how deep you get, it will directly relate to how you can trade space for time or reduce communication costs to save on time. And yes even historically there were very popular network protocols where they would append the same element to a set and shift the complexity from insert time to read time. To be clear I am not asserting any claim of better outside of local context to doing so. You are absolutely correct that no production quality RDBMs are based on Codd's rules. That absolutely doesn't change the fact of what the term 'relational model' means, nor does it remove the reality that they follow enough of it so that where it breaks, even from a set centric perspective, is directly related to that origin. Especially in parallel, distributed systems that are the norm now. And the fact that things moved, doesn't change the reality that the 'relation' in the 'relational model' is as described in previous posts.

9rx 1y ago

> the relational part of the relational model is attributes or column names The relational part is defined, most importantly, by the set. That was key to Codd's model, and the source of his primary criticism of SQL. But his ideas went out of fashion long ago. Postgres, pre-1995, was the last time we saw a relational database anyone heard of. Sure, there have been some esoteric attempts more recently to revive the concept, but they never went anywhere. For all intents and purposes the relational model is dead. We live in a tablational world now. > it is equivalent. It is not, though. In fact, I posit that lists/multisets are easier to reason about, at least where one doesn't have a strong mathematical understanding (i.e. the layman), and that is why SQL "won". A list, if carefully constrained, can represent a set — which is maybe what you are struggling to suggest — but that does not make it a set.

nyrikki 1y ago
Can you provide any specific situation where the following does not hold? Especially if I add the constraint that rows have to be unique? Relations=Tables Rows=Tuples Columns=Attributes I think we may be from different schools of set theory, where I am from the more abstract direction, where set membership, inclusion and equality are separate concepts and don't need to be decided on to define a relation. Not that my view is better just different. I just happened to come through the {{foo},{foo}}=={{foo}} school.
- 9rx 1y ago
  > Especially if I add the constraint that rows have to be unique?; Relations=Tables This is kind of like saying that a dynamically-typed programming language is statically-typed because you can add tests to enforce the same constraints as what static typing enables. There is a lot of truth in that statement, but you completely fail to capture the differences in calling said language statically-typed. And, sure, for a silly comment on HN, who cares, right? But on the other hand, what are you gaining by obscuring the differences? It is not like said programming language is somehow better because you call it statically-typed. It is still the same language no matter what you call it. SQL does not follow the relational model, as it was proposed by Codd. And that's okay. Arguably it is better because of it. Why not call it what it is? > Not that my view is better just different. Of course you can view things however your little heart desires. You can even see what I call a chicken as being a relational database if that is what floats your boat. But we are not talking about your view, we are talking about Codd's view. Every single comment that preceded this was clearly about Codd's take, to the point that you even linked to some of his work for us to engross in his thoughts. And we know very well how Codd felt about tables. He wrote about everything he thought was wrong with SQL at length.
  - nyrikki 1y ago
    No, you are confusing convention and simplifications for convenience for fundamental properties.. What is generally considered Standard set theory today is typically ZF(C), which can be viewed and was intentionally developed as what is not called a "material set theory" or sometimes a "membership based set theory" In ZF(C), sets are characterized only by the binary “∈” operation and propositional equality of sets. It is actually the less common schools like the Elementary Theory of the Category of Sets (ETCS), where individual elements have no identity and must be unique. There are well documented disagreements between Zermelo and Frege vs Cantor and Lawvere, was the former was for membership and the later were against it. With ∈ or "is a member of" both of the following hold: Given a set A={1,2,3,4}; 3 ∈ A Given a set A={1,1,2,2,3,3,4,4}; 3 ∈ A There is value in defining things like multisets/bags and accessing concepts like multiplicity, but you could use a function you defined for a multiset and discard that information and it would fit the axioms of ZF. In computer science and databases, this is less than just a trivial factoid depending how deep you get, it will directly relate to how you can trade space for time or reduce communication costs to save on time. And yes even historically there were very popular network protocols where they would append the same element to a set and shift the complexity from insert time to read time. To be clear I am not asserting any claim of better outside of local context to doing so. You are absolutely correct that no production quality RDBMs are based on Codd's rules. That absolutely doesn't change the fact of what the term 'relational model' means, nor does it remove the reality that they follow enough of it so that where it breaks, even from a set centric perspective, is directly related to that origin. Especially in parallel, distributed systems that are the norm now. And the fact that things moved, doesn't change the reality that the 'relation' in the 'relational model' is as described in previous posts.