> Either way I have provided actual cites and would appreciate the same
You did, but I am not sure why. Best to come to a discussion to discuss it yourself. If you have to rely on third-parties to write for you, why bother participating at all?
But, for the sake of trying to demonstrate good faith, I'll break my rule of not providing citations this once and give you this:
Codd, E.F. (1988) Fatal Flaws in SQL:
"Relations in the relational model and in mathematics do not have duplicate rows."
In contrast, SQL does have duplicate rows, as Codd defines that. Hence why we call what SQL has "tables" instead of "relations", even though at the end of the day they serve the same purpose. SQL is unquestionably inspired by the relational model, but it, itself, is not relational as Codd saw it.
If you want to still call it as such, go nuts! You can call it a "flying monkey" for all anyone cares. But, if you do call SQL relational, I am interested in what you would call a database that does adhere strictly to Codd's model since also calling it relational wouldn't paint an accurate picture. There are clear differences, as you even told earlier.
That 1988 paper was a modification of the previous design,as an attempt to address criticisms, but thank you for the cite.
It is important to realize that relations are abstract data structures that we treat like sets, not objects we constructed from sets.
If you want to do the set specific approach, reviewing any books on basic set theory and their intentional and extensional set definitions with show your argument is confusing the map for the territory.
The set operations applied to relations produce relations or relations of relations.
Same in material set theory, excluding membership, the only set operation that isn't predicated, this operating on the set, and not opening it up to act on its members.
While the platonic ideal may seem to make it seem different, urelements/atoms/individuals are not what those operations are acting on.
That is what made ZF(C) different.
Remember that Codd was targeting the hierarchical model, records etc...
While the other camp was targeting the network model, specifically using lists.
From the platonic view, uniqueness is a trivial, syntax property, you make that choice, and it has costs.
The typical example is I am a person who lives in (a member) the US, and the US is a member of the UN. Yet I am not a member of the UN.
Similar challenges are why Codd added Recursive CTEs to capture some of the expressiveness of the network model, which OOP is related to.
The problems Codd was targeting in your cite were mostly addressed post SQL99 with the addition of structural data options, specifically challenges with foreign keys.
The intersection of a column and a row being a field, which maps to cobol record concepts is why tables and relations are equal.
If you look at the 1970 paper I provided above, you can see where his concrete implementation using arrays calls out it isn't equal and requires distinct entries.
Note the link to the author's page allowing you to download the Alice book in its entirety works now.
I encourage you to get it.
The concept of a relation as a data structure is far more abstract than it seems.
Yes Codd did attempt to become more prescriptive later, but there is a reason no one exactly implemented it, just like platonic ideals it doesn't really work for real world needs, nor is it required for ACID transactions.
But the relation is still a binary operations that is equivalent to a table.
> That 1988 paper was a modification of the previous design,as an attempt to address criticisms
That paper is the criticism (of SQL). Is the contention here simply about not understanding that we're talking about what Codd thought, not what others thought/think? It seems abundantly clear what Codd thought. His language doesn't offer a whole lot of ambiguity as far as I am concerned.
> The concept of a relation as a data structure is far more abstract than it seems.
If you want to interpret that way, sure. You can imagine a relation any way you want. But that's not what we're talking about.
> From the platonic view, uniqueness is a trivial, syntax property, you make that choice
Absolutely. Akin to choosing to define your program constraints in tests instead of using a type system. The end result is effectively the same, but one offers certain guarantees out of the box, while the other relies on you to get things right. They, while effectively the same, are not identical. There is good reason why we have static and dynamic typed classifications, just as we have relational and tablational. There is not some kind of magic in there, it is merely a communication device so that others can figure out what you are trying to say.
> but there is a reason no one exactly implemented it
Right, because the relational model, as Codd saw it, isn't really all that good, at least not in real-world scenarios. Just as we've brought up many times before. There is good reason why SQL "won". Why embarrass SQL by calling it relational?
But, if you wish to — and fair enough if you do, I would still love to know what you would call a database that is built in the eye of Codd? It cannot also be relational if SQL is deemed as such. As you point out, there are clear differences. Calling them both relational would be confusing.
Comments
> Either way I have provided actual cites and would appreciate the same
You did, but I am not sure why. Best to come to a discussion to discuss it yourself. If you have to rely on third-parties to write for you, why bother participating at all?
But, for the sake of trying to demonstrate good faith, I'll break my rule of not providing citations this once and give you this:
In contrast, SQL does have duplicate rows, as Codd defines that. Hence why we call what SQL has "tables" instead of "relations", even though at the end of the day they serve the same purpose. SQL is unquestionably inspired by the relational model, but it, itself, is not relational as Codd saw it.If you want to still call it as such, go nuts! You can call it a "flying monkey" for all anyone cares. But, if you do call SQL relational, I am interested in what you would call a database that does adhere strictly to Codd's model since also calling it relational wouldn't paint an accurate picture. There are clear differences, as you even told earlier.
That 1988 paper was a modification of the previous design,as an attempt to address criticisms, but thank you for the cite.
It is important to realize that relations are abstract data structures that we treat like sets, not objects we constructed from sets.
If you want to do the set specific approach, reviewing any books on basic set theory and their intentional and extensional set definitions with show your argument is confusing the map for the territory.
The set operations applied to relations produce relations or relations of relations.
Same in material set theory, excluding membership, the only set operation that isn't predicated, this operating on the set, and not opening it up to act on its members.
While the platonic ideal may seem to make it seem different, urelements/atoms/individuals are not what those operations are acting on.
That is what made ZF(C) different.
Remember that Codd was targeting the hierarchical model, records etc...
While the other camp was targeting the network model, specifically using lists.
From the platonic view, uniqueness is a trivial, syntax property, you make that choice, and it has costs.
The typical example is I am a person who lives in (a member) the US, and the US is a member of the UN. Yet I am not a member of the UN.
Similar challenges are why Codd added Recursive CTEs to capture some of the expressiveness of the network model, which OOP is related to.
The problems Codd was targeting in your cite were mostly addressed post SQL99 with the addition of structural data options, specifically challenges with foreign keys.
The intersection of a column and a row being a field, which maps to cobol record concepts is why tables and relations are equal.
If you look at the 1970 paper I provided above, you can see where his concrete implementation using arrays calls out it isn't equal and requires distinct entries.
Note the link to the author's page allowing you to download the Alice book in its entirety works now.
I encourage you to get it.
The concept of a relation as a data structure is far more abstract than it seems.
Yes Codd did attempt to become more prescriptive later, but there is a reason no one exactly implemented it, just like platonic ideals it doesn't really work for real world needs, nor is it required for ACID transactions.
But the relation is still a binary operations that is equivalent to a table.
> That 1988 paper was a modification of the previous design,as an attempt to address criticisms
That paper is the criticism (of SQL). Is the contention here simply about not understanding that we're talking about what Codd thought, not what others thought/think? It seems abundantly clear what Codd thought. His language doesn't offer a whole lot of ambiguity as far as I am concerned.
> The concept of a relation as a data structure is far more abstract than it seems.
If you want to interpret that way, sure. You can imagine a relation any way you want. But that's not what we're talking about.
> From the platonic view, uniqueness is a trivial, syntax property, you make that choice
Absolutely. Akin to choosing to define your program constraints in tests instead of using a type system. The end result is effectively the same, but one offers certain guarantees out of the box, while the other relies on you to get things right. They, while effectively the same, are not identical. There is good reason why we have static and dynamic typed classifications, just as we have relational and tablational. There is not some kind of magic in there, it is merely a communication device so that others can figure out what you are trying to say.
> but there is a reason no one exactly implemented it
Right, because the relational model, as Codd saw it, isn't really all that good, at least not in real-world scenarios. Just as we've brought up many times before. There is good reason why SQL "won". Why embarrass SQL by calling it relational?
But, if you wish to — and fair enough if you do, I would still love to know what you would call a database that is built in the eye of Codd? It cannot also be relational if SQL is deemed as such. As you point out, there are clear differences. Calling them both relational would be confusing.