Re: Sensible and NonsenSQL Aspects of the NoSQL Hoopla

Am Mittwoch, 21. August 2013 19:17:09 UTC+2 schrieb Eric:
> On 2013-08-21, karl.scheurer_at_o2online.de <karl.scheurer_at_o2online.de> wrote:
>
>
> > - With database cursors and indizes there are only "Not only SQL" systems.
>
>
>
> That's just confusing.
>
Why? with database cursor You can traverse a table in a very old fashioned navigational way (first, next, last, previous). Indizes are logical data structures when efficient subsets are essential (conditional indizes)
>

>
> > - 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.
>
As a programmer I don't see the advantage of a "partial" logical view to real life structures. A "mathematical" relation can be implemented as a incomplete view on a more complex structure. A "computational" relation has relation and tuple identities and a life before and after filled with data. As long as I see no alternative working implementation I see no use for such a limited "logical model"

>
>
> 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.
>
>
Wrong!
It's no problem to create Your own "system catalogs". We have done this for a application when we integrate our regulation database into a workflow system. The real problem is the missing standard.
>
>
> 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.
>
Maybe I gave Codd to much credit for his reasoning. Based on my experiences with these languages it seems to be reasonable to shift complexity in a easier manageable area (tuple fractioning). "Since more complicated data structures" became part of standard libraries, I see no reason to cope with exploding numbers of tables when simpled solutions exists.
>
>
> > - 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!
>
Wrong!
- Try column-wise storage on a relation with composite primary key - Try export a Access database table to a Excel worksheet and reimport   the data and compare the tables.

>
>
> 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.
>

"It's not a bug, it's a feature". Tables can have inheritance (at least in Postgres).

"Missing data and identity are not problems anyway" is a very bold statement without limit it to Your field of work. We develop applications for inspection and maintainance of powerplants. Missing data is a problem for us without a system created identity.

>
>
> 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.
>
You are partially right. Storing application objects in "objectrepositories" is indeed ridiculous. Separating applications and databases is no argument against a object view to databases. Though no Microsoft fan I believe the ADO framework is a step in the right direction. ADO's "Datasets" are "relation objects".

m.f.G.
Karl Scheurer Received on Thu Aug 22 2013 - 10:48:22 CEST