Re: Sensible and NonsenSQL Aspects of the NoSQL Hoopla

On 2013-08-26, karl.scheurer_at_o2online.de <karl.scheurer_at_o2online.de> wrote:
> Am Sonntag, 25. August 2013 15:38:37 UTC+2 schrieb Eric:
>

Plenty of point-by-point answers possible if I had time, but since I may not, I have picked out the one statement (and broken it up a bit) that had most impact on me:

> What is the benefit of "logical model" that cannot be mapped lossless to
> a physical storage?

That it is logical? In any case I am not claiming that it cannot be mapped to physical storage, just that it may be different.

> Sorry, but relations are abstractions of "record
> oriented" storages.

No, relations are an adaptation of a mathematical concept to which you can map your real-world data so that there is a clearly defined set of logical (and logically correct) operations for manipulating that data. If you try to show a relation on paper it looks like a table, which in turn looks like "record-oriented" storage (though you could draw the table the other way, in which case it looks like "column-oriented" storage). In every case "looks like" is an analogy, not an exact equivalence.

> Primary key is the y-coordinate and column-names are
> the correspondent x coordinates.

You can think of like that if you wish, there is no overriding reason to store it like that.

> Column oriented storages need a alternative
> y-address.

And for efficient use, record-oriented storage requires indexes, whereas carefully designed column-wise storage removes the need for many (or even most) of them.

Physical storage of a relation that is exactly record-oriented storage is only justifiable for efficiency if you are retrieving all "records" that correspond to a single relation. Add in any conditions or joins and you need "complications" of the storage to allow efficient retrieval.

The relations (tables if you must) that you use are given to you by an abstraction layer that is the business of the RDBMS you use. It may offer multiple storage methods, accompanied by advice on when each is appropriate. A good, experienced DBA for that RDBMS will be able to improve on that advice.

To be honest I think your database is a tool you are using without sufficient understanding, particularly of the theory behind it. I don't doubt that your systems do what is expected of them efficiently enough, but how easy is it to keep them doing that in the face of changing operational requirements and the appearance of unanticipated reporting requirements?

Eric

-- 
ms fnd in a lbry