Why not relational ordering operators?
Quote from dandl on May 17, 2020, 11:14 pmQuote from Erwin on May 17, 2020, 8:47 amQuote from dandl on May 17, 2020, 2:16 amRM Pro 2 says:
D shall include no concept of a “relation” whose tuples are distinguishable by ordinal position. Instead, for
every relation r expressible in D, the tuples of r shall be distinguishable by value.A relational ordering operator means the definition of a less function. As per RM Pro 2 brief discussion in DTTRM, the operator is not relational, it is a generic operator with two tuple arguments of the same type and returning a Boolean result. There is no concept of 'distinguished by ordinal position', but it would enable some useful queries, such as first, last, skip, take, lead, lag and rank.
I find the idea mooted in DTATRM and found in TD of having a separate ARRAY type absolutely pointless and unnecessary; the ordering operator solution is simple and self-evident. Without this, SQL does the job better.
What job ?
"No concept of tuples distinguished by ordinal position" does ***not*** mean that "some useful queries" are ruled out. They are not ruled out. Re-read the information principle. If information is relevant to the user, then that information shall be present as ***values of attributes in tuples in relations***. The only thing forbidden is that the system starts offering facilities that go beyond this rule, such as, e.g., "ordered" relations where "position of a tuple" has a material effect on, e.g., the results of the relation equality operator, that is to say, where "equality of ordered relations" is like java's LinkedList.equals() and not Set.equals(). What is manifestly not forbidden, is relations whose heading includes a RANK or ORDINAL_POS attribute. Fits the IP perfectly, and is therefore the way to go for your "some useful queries".
I think you're agreeing with me. TTM does not forbid attributes of that kind, and presumably the operators required to compute them. The function
less(tuple,tuple)is such an operator.
For tuples of degree n, there are n! such functions that provide a total ordering (and then I'm disregarding cases of orderings that involve less than the entire set of attributes, which might lead to cases of having to deal with ties). Your use of 'The' is confused and unwarranted. Or a sign of utter sloppiness.
Quote from Erwin on May 18, 2020, 9:27 amQuote from dandl on May 17, 2020, 11:14 pmQuote from Erwin on May 17, 2020, 8:47 amQuote from dandl on May 17, 2020, 2:16 amRM Pro 2 says:
D shall include no concept of a “relation” whose tuples are distinguishable by ordinal position. Instead, for
every relation r expressible in D, the tuples of r shall be distinguishable by value.A relational ordering operator means the definition of a less function. As per RM Pro 2 brief discussion in DTTRM, the operator is not relational, it is a generic operator with two tuple arguments of the same type and returning a Boolean result. There is no concept of 'distinguished by ordinal position', but it would enable some useful queries, such as first, last, skip, take, lead, lag and rank.
I find the idea mooted in DTATRM and found in TD of having a separate ARRAY type absolutely pointless and unnecessary; the ordering operator solution is simple and self-evident. Without this, SQL does the job better.
What job ?
"No concept of tuples distinguished by ordinal position" does ***not*** mean that "some useful queries" are ruled out. They are not ruled out. Re-read the information principle. If information is relevant to the user, then that information shall be present as ***values of attributes in tuples in relations***. The only thing forbidden is that the system starts offering facilities that go beyond this rule, such as, e.g., "ordered" relations where "position of a tuple" has a material effect on, e.g., the results of the relation equality operator, that is to say, where "equality of ordered relations" is like java's LinkedList.equals() and not Set.equals(). What is manifestly not forbidden, is relations whose heading includes a RANK or ORDINAL_POS attribute. Fits the IP perfectly, and is therefore the way to go for your "some useful queries".
I think you're agreeing with me. TTM does not forbid attributes of that kind, and presumably the operators required to compute them. The function
less(tuple,tuple)is such an operator.For tuples of degree n, there are n! such functions that provide a total ordering (and then I'm disregarding cases of orderings that involve less than the entire set of attributes, which might lead to cases of having to deal with ties). Your use of 'The' is confused and unwarranted. Or a sign of utter sloppiness.
I think your maths is dodgy. That would be correct for a simple ORDER BY on exactly N attributes, ascending only. What Andl has is an operator that does order by a list of attributes, with a descending option for each. Which is probably what you had in mind, but didn't express very well. This raises the count by N^2, considering only the attributes selected.
This time I proposed a less template function instead, since it requires no special syntax, is more general, and can more easily be implemented in my 'C# as D' project. But feel free to choose, the range of queries enabled is the same either way.
but there is an infinite range of computations that could be applied to each attribute. Where would 'order by day of week
OTOH I propose exactly one less template function that covers them all.