Re: Sensible and NonsenSQL Aspects of the NoSQL Hoopla

On 2013-09-02, karl.scheurer_at_o2online.de <karl.scheurer_at_o2online.de> wrote:
> Am Sonntag, 1. September 2013 19:49:48 UTC+2 schrieb Eric:
>
>>
>> In what way is the relational model insufficiently complete?
>>
>
> In my line of work the most frustating limit of the relational model
> is the omission of the order of tuples. Sorting part of SQL and not
> part of Codd's relational model.

As paul c says in another post in this thread, ordering depends on domain-specific operators, and adds a lot of extra complexity if the model is to remain logical and consistent, to the point where that may not even be possible.

I think you are somehow missing two things here. Firstly, relations are unordered sets because that is what the mathematical definition of a relation is, and also because Codd was trying to eliminate order dependencies which existed in many systems of the time, i.e. he was, in effect, banning any implementation which forced applications to process some data in an order determined by the storage method.

Secondly, ordering is conceptually a post-retrieval operation (and yes, outside the relational model), but there is nothing to forbid being able to ask the DBMS to return data in a order you specify, which it may do, either by actual sorting or by (if it can in any particular case) exploiting its internal storage structures to produce the requested order more efficiently. There is also nothing to forbid being able to tell the DBMS to use storage methods that make retrieving certain orders efficient as long as that does not make any possible order prohibitively inefficient. That ability is nothing to do with the DBMS's correctness in following relational theory, it is merely twiddling dials on the implementation.

> Even if sorting is entered through the back door it remains a tool to
> beautify the output

or, presumably, to specify the processing order for non-relational operations on a result-relation after you have retrieved it,

> and cannot be exploited while querying, since relations are unordered
> sets.

How do you want to exploit order while querying? "Top n" and analogous results come from what I have already said ...

> Don't know if grouping and querying groups can be comprehend without
> reference to sorting order,

... and a group is simply a subset of the tuples in a relation for which some element(s) of each tuple have a particular (set of) values.

> since viewing and analyzing groups as a sorted list
> is easy to communicate and to implement.

I think you are thinking only of algorithms, that is, of process more than results. A bit like those people who ask "how do I do x" and then reveal in their answer to "why do you want to do x?" that they should go back a couple of steps and then do p and q instead, because then they will get the result they want.

> Hiding these algorithms behind "macro" functions like done in SQL is
> not the problem.

Of course not, algorithms are meant to be hidden in functions. It is not the problem, but it is not the point either.

>> Ordering and grouping are not part of the data definition, they are
>> operations.
>
> Grouping are part of the data definition:
>
> employes are a set of (teachers, assistents, secretaries ...)
>
> Every set with potential subsets can be defined with groups

Indeed, but I have already said that grouping does not require ordering. The fact that ordering may be a suitable implementation algorithm is not relevant because it is happening behind the scenes.

Eric

-- 
ms fnd in a lbry