Re: Sensible and NonsenSQL Aspects of the NoSQL Hoopla

On 2013-08-21, karl.scheurer_at_o2online.de <karl.scheurer_at_o2online.de> wrote:
> Am Freitag, 22. M?rz 2013 10:29:10 UTC+1 schrieb Jan Hidders:
>> One of the best and most insightful reads in the SQL vs noSQL debate
>>
>> I've seen lately:
>>
>>
>>
>> http://www.edbt.org/Proceedings/2013-Genova/papers/edbt/a2-mohan.pdf
>>
>>
>>
>> -- Jan Hidders
>
> It's a nice paper, but due to sloppy terminology it misses vital points:
>
> - With database cursors and indizes there are only "Not only SQL" systems.

That's just confusing.

> - Transactions are no part of the relational model

No, they are orthogonal to it. Codd's original paper contains the word only once, in relation to checking for inconsistencies in data, and it seems that he is viewing them as part of the known universe.

> - The relational modell is never "correct" implemented. Without "holographic"
> storage media I see no way to implement "tables" where "row- and column
> order are insignificant". Defining relations as a "interface" views of
> storage objects leads to practical, but "pseudo" relational systems.

You do not appear to be aware of the difference between logical and physical models.

> - The real problem of NoSQL systems is the missing of a standard for "system
> catalogs" as a repository for metadata. Mixing metadata and data as a
> solution for large "sparse" tables is nice, but not a full substitute for
> a metadata repository.

As far as I can see NoSQL systems don't have "system catalogs" because the data in them is insufficiently organised to allow one to be designed. However, whether or not this is a real problem for them has got nothing to do with any other argument about their merits relative to SQL or the relational model or anything else.

> The "SQL vs noSQL debate" is fruitless, unless Codd's theory will finally
> be consolidated. Looking into Codd's paper of 1970 You will find:
>
> - Normalization and 1NF is a "workaround" to avoid "too complicated
> datastructures". A sound idea 1970 with Fortran, Assembler and PreAnsiC
> it was never revised

Codd does not use the word "workaround". He says that "... more complicated data structure is necessary for a relation with one or more nonsimple domains" and so "the possibility of eliminating nonsimple domains appears worth investigating!" and that "there is, in fact, a very simple elimination procedure, which we shall call normalization." Not a workaround, and nothing to do with how old-fashioned the languages being used are.

> - Defining relations and tuples only via it's contents limits the "physical
> data independence" to "record oriented storages". "Column oriented storages"
> needs additional data for mapping (rowid)

Once again, you do not appear to be aware of the difference between logical and physical models. A relational implementation could quite easily use column-wise storage instead of or as well as any other storage structure without imposing any limitations on its faithfulness to the relational model. It's just an implementation layer, not part of the relational model!

> - Relation and tuples seems to e a blurred vision of object oriented storage
> management. Accepting the object nature of relations and tuples, many
> problems (missing data, identity, table inheritance ... ) simply disappear

Relations and tuples do not have an object nature, they are not objects. Tables do not have inheritance, they are relations which are not objects. Missing data and identity are not problems anyway.

The whole object thing is a methodology which can be very helpful to programmers, if done correctly, but it is harder than most programmers think to do correctly. It has nothing whatever to do with "Large Shared Data Banks". The key word in that phrase is "Shared", a fact that most proponents of "objects" do not seem to get at all.

Eric

-- 
ms fnd in a lbry