# Which Set Theory?

**Page 2 of 2**

Quote from dandl on November 10, 2021, 6:16 amI understand your philosophical preference, but others make different choices.

The only thing that can ever supplant SQL is beyond SQL. If you start with the things you don't want, then nobody will want what you have. So the challenge is how to go above and beyond. There are so many things SQL can do that TTM cannot, and vice versa. You can find tiny niches with your purist approach, but for the mainstream the only opportunity is to do both and then some.

To your specifics: there is no great harm in supporting nulls and duplicate rows, and real advantages in having them available. Nulls are just values, duplicate rows (bags) can be useful at times. Duplicate/anonymous columns names are an artefact of the SQL language as it stands, they fall away in a superset model as the language evolves.

There are plenty of things wrong with SQL and its ecosystem to target. Those are the things that matter to the target users, not getting picky about historical oddities.

I understand your philosophical preference, but others make different choices.

The only thing that can ever supplant SQL is beyond SQL. If you start with the things you don't want, then nobody will want what you have. So the challenge is how to go above and beyond. There are so many things SQL can do that TTM cannot, and vice versa. You can find tiny niches with your purist approach, but for the mainstream the only opportunity is to do both and then some.

To your specifics: there is no great harm in supporting nulls and duplicate rows, and real advantages in having them available. Nulls are just values, duplicate rows (bags) can be useful at times. Duplicate/anonymous columns names are an artefact of the SQL language as it stands, they fall away in a superset model as the language evolves.

There are plenty of things wrong with SQL and its ecosystem to target. Those are the things that matter to the target users, not getting picky about historical oddities.

Quote from Vadim on November 10, 2021, 3:43 pmQuote from AntC on November 10, 2021, 4:59 amThe

less thanrelation is compatible with (i.e. invariant to) the addition operation as evidenced by the bold Boolean value in the bottom right corner. I'm currently puzzled by the fact that the Functional Dependency {x,y} -> {x+y} induced by the addition operation is oriented the weird way vertically, as opposed to what we have in Database Dependency Theory...That's because you have a table trying to show two different relations orthogonally. For the

`+`

relation, you need`{x, y, (x+y)}`

to be attributes (conventionally shown as columns -- but of courseTTMdeliberately abstracts away from a spatial organisation, precisely because thinking in columns and rows will confound you).Not sure what you mean by

less thanbeing invariant. Throw in a few negative integers, that'll soon mess it up. For example`{ x (-5), y (+10), x+y (+5)}`

. Now you can't swizzle that into`{u, v}`

columns such that the invariant holds.

That was definition of invariant relation from Universal Algebra (which has little to do with TTM). In every instance of an algebra there is an underlying set of elements and, as you correctly noticed, in my example it has to be a positive set of numbers. Another example would be a set of integers (positive and negative) with addition operation, where the unary relation "is even number" is invariant.

There is much more to it than the paragraph above, of course. I'm fascinated by this connection between the world of n-ary relations, and the world of n-ary functions (operations).

Quote from AntC on November 10, 2021, 4:59 amThe

less thanrelation is compatible with (i.e. invariant to) the addition operation as evidenced by the bold Boolean value in the bottom right corner. I'm currently puzzled by the fact that the Functional Dependency {x,y} -> {x+y} induced by the addition operation is oriented the weird way vertically, as opposed to what we have in Database Dependency Theory...That's because you have a table trying to show two different relations orthogonally. For the

`+`

relation, you need`{x, y, (x+y)}`

to be attributes (conventionally shown as columns -- but of courseTTMdeliberately abstracts away from a spatial organisation, precisely because thinking in columns and rows will confound you).Not sure what you mean by

less thanbeing invariant. Throw in a few negative integers, that'll soon mess it up. For example`{ x (-5), y (+10), x+y (+5)}`

. Now you can't swizzle that into`{u, v}`

columns such that the invariant holds.

That was definition of invariant relation from Universal Algebra (which has little to do with TTM). In every instance of an algebra there is an underlying set of elements and, as you correctly noticed, in my example it has to be a positive set of numbers. Another example would be a set of integers (positive and negative) with addition operation, where the unary relation "is even number" is invariant.

There is much more to it than the paragraph above, of course. I'm fascinated by this connection between the world of n-ary relations, and the world of n-ary functions (operations).

**Page 2 of 2**