5 ms·

The 'relation' in the relational model is the tables, specific named columns and tuples, with specific abstracts [0] The relation is the table, normalization,

The 'relation' in the relational model is the tables, specific named columns and tuples, with specific abstracts [0] The relation is the table, normalization, foreign keys, candidate keys etc are all extensions to that base model for Codd. Some of the impedance mismatch is due to that, and not just the declarative nature or extensions Specifically I think the Alice book covers how with a candidate key + the remaining tuples in the row form the row but only the candidate key has an identity, the rest of the row is a substring. Some quotes from the link, but searching for 'user' will hit what I think justifies my interpretation. > Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation). > To sum up, it is proposed that most users should interact with a relational model of the data consisting of a collection of time-varying relationships (rather than relations). Each user need not know more about any relationship than its name together with the names of its domains (role qualified whenever necessary): Even this information might be offered in menu style by the system (subject to security and privacy constraints) upon request by the user. [0] https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf

9rx 1y ago
> The 'relation' in the relational model is the tables No. A table is a list/multiset of tuples, while a relation is a set of tuples. If you squint hard enough they might look similar, but they are not the same. The relational model has no concept of tables. > Some of the impedance mismatch is due to that ORM doesn't really have an impedance mismatch in and of itself. It is just a data transformation. The impedance mismatch that is oft spoken of in association with ORM revolves around the N+1 problem. This is where you get some bizarreness that has to lean on hacks to overcome the real-world constraints that the mathematical model doesn't account for. If you are using something like SQLite that isn't so much of a problem in practice, of course.
- nyrikki 1y ago
  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.

9rx 1y ago

> The 'relation' in the relational model is the tables No. A table is a list/multiset of tuples, while a relation is a set of tuples. If you squint hard enough they might look similar, but they are not the same. The relational model has no concept of tables. > Some of the impedance mismatch is due to that ORM doesn't really have an impedance mismatch in and of itself. It is just a data transformation. The impedance mismatch that is oft spoken of in association with ORM revolves around the N+1 problem. This is where you get some bizarreness that has to lean on hacks to overcome the real-world constraints that the mathematical model doesn't account for. If you are using something like SQLite that isn't so much of a problem in practice, of course.

nyrikki 1y ago
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.