3 ms·

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 Row

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
    No. You are getting confused by semantics. It is understood that definitions are just made up on the spot and anyone can define anything however they like. That was never in question. However, we are specifically talking about Codd. His definition for the relational model does not match anything we use today. Tablational databases are something quite different. So, sure, you can call what I call dynamically-typed languages statically-typed if you want. You're not wrong. Definitions cannot be wrong, fundamentally. But it is different, and since we're not talking about your definition and never were...
    - nyrikki 1y ago
      From [0] which is Codd justifying it explicitly. > The term relation is used here in its accepted mathematical sense. Given sets S_1, S_2, ..., S_n (not necessarily distinct), R is a relation on these n sets if it is a set of ntuples each of which has its first element from S_1, its second element from S_z , and so on.’ We shall refer to S_i as the jth domain of R. Note the "(not necessarily distinct)" part and how he uses a table to describe it on the same page. From what is called the "Alice book" Foundations of Databases - Abiteboul, Hull, Vianu[1] the seminal textbook in database theory. > In the 1970s, Codd’s relational model revolutionized the field. In this model, humans view the data as organized in relations (tables), and more “declarative” languages are provided for data access. Unfortunately I can't find chapter 3, where the relational model is described in detail online. But for more concrete SQL as defined in ISO/IEC 9075-2:1999 (E)[2]....calls them "tables" Outside of didactic simplifications or domain specific conventions I am not finding anything. I could be convinced otherwise...but as every real world practical RDBMS has to impose order of often multple tables to scale, through logs, cache etc...and as what everyone agrees is SQL has to support various transaction isolation levels which ensures that on a concrete implementation detail, that rows aren't unique, but that the special case of a membership function, expressly being an 'element' is supported in them all. Plus you only get DISTINCT with a candidate key, and by default SQL is using bags/multisets anyway...there is just to much undefined behavior with indistinct rows and so we avoid them but they are allowed. In fact, while useful for teaching and day to day use, you are actually violating the axiom of pairing, which is also used to construct the singleton's in modern ZFC. In fact AC is called the well-ordering axiom by some, expressly because it allows it. I think you are possibly confusing the absence of ordering from the users perspective? Either way I have provided actual cites and would appreciate the same, because I would rather learn where I am wrong than prove myself right. [0] https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf [1] http://webdam.inria.fr/Alice/pdfs/Chapter-1.pdf http://webdam.inria.fr/Alice/pdfs/Chapter-1.pdf [2] https://web.cecs.pdx.edu/~len/sql1999.pdf https://web.cecs.pdx.edu/~len/sql1999.pdf

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
  No. You are getting confused by semantics. It is understood that definitions are just made up on the spot and anyone can define anything however they like. That was never in question. However, we are specifically talking about Codd. His definition for the relational model does not match anything we use today. Tablational databases are something quite different. So, sure, you can call what I call dynamically-typed languages statically-typed if you want. You're not wrong. Definitions cannot be wrong, fundamentally. But it is different, and since we're not talking about your definition and never were...
  - nyrikki 1y ago
    From [0] which is Codd justifying it explicitly. > The term relation is used here in its accepted mathematical sense. Given sets S_1, S_2, ..., S_n (not necessarily distinct), R is a relation on these n sets if it is a set of ntuples each of which has its first element from S_1, its second element from S_z , and so on.’ We shall refer to S_i as the jth domain of R. Note the "(not necessarily distinct)" part and how he uses a table to describe it on the same page. From what is called the "Alice book" Foundations of Databases - Abiteboul, Hull, Vianu[1] the seminal textbook in database theory. > In the 1970s, Codd’s relational model revolutionized the field. In this model, humans view the data as organized in relations (tables), and more “declarative” languages are provided for data access. Unfortunately I can't find chapter 3, where the relational model is described in detail online. But for more concrete SQL as defined in ISO/IEC 9075-2:1999 (E)[2]....calls them "tables" Outside of didactic simplifications or domain specific conventions I am not finding anything. I could be convinced otherwise...but as every real world practical RDBMS has to impose order of often multple tables to scale, through logs, cache etc...and as what everyone agrees is SQL has to support various transaction isolation levels which ensures that on a concrete implementation detail, that rows aren't unique, but that the special case of a membership function, expressly being an 'element' is supported in them all. Plus you only get DISTINCT with a candidate key, and by default SQL is using bags/multisets anyway...there is just to much undefined behavior with indistinct rows and so we avoid them but they are allowed. In fact, while useful for teaching and day to day use, you are actually violating the axiom of pairing, which is also used to construct the singleton's in modern ZFC. In fact AC is called the well-ordering axiom by some, expressly because it allows it. I think you are possibly confusing the absence of ordering from the users perspective? Either way I have provided actual cites and would appreciate the same, because I would rather learn where I am wrong than prove myself right. [0] https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf [1] http://webdam.inria.fr/Alice/pdfs/Chapter-1.pdf http://webdam.inria.fr/Alice/pdfs/Chapter-1.pdf [2] https://web.cecs.pdx.edu/~len/sql1999.pdf https://web.cecs.pdx.edu/~len/sql1999.pdf