Re: Sensible and NonsenSQL Aspects of the NoSQL Hoopla

Am Sonntag, 1. September 2013 18:53:22 UTC+2 schrieb James K. Lowden:

>
> If you remove "hardware-determined" from the sentence, it's exactly as
>
> true now as then.
>
if you remove hardware-determined from the sentence, then it's no difference between pointers and foreign keys.
>
>
> > 1.2.2. Indexing Dependence.
>
> > "...destroy indices from time to time will probably be necessary. The
>
> > question then arises: Can application programs and terminal
>
> > activities remain invariant as indices come and go?..."
>
> >
>
> > In the seventies "bigdata" had to be stored on sequential data
>
> > storages (tapes, cards). Querying data from sequential media cannot
>
> > use indices ("indices go").
>
>
>
> Hmm, no, I'm pretty sure VSAM and IMS were available in the 70s.
>
> Cullinet was selling IDMS.
>
Maybe! In the 70s storage was very expensive and indices are additional costs. Using a model without the need for indices sounds attractive

>
> > 1.2.3. Access Path Dependence.
>
> > "
>
> > One solution to this is to adopt the policy that once a
>
> > user access path is defined it will not be made obsolete until
>
> > all application programs using that path have become
>
> > obsolete. Such a policy is not practical, because the number
>
> > of access paths in the total model for the community of
>
> > users of a data bank would eventually become excessively
>
> > large."
>
> >
>
> > That statement is based on the hardware of the seventies.
>
>
>
> On the web I believe it's called "404".
>
No! with cheap storage it can be reasonable to keep all user access path, at least the policy has to be reconsidered.

>
> > For reasons not comprehensible any more (Codd's reference is
>
> > out of print and not online available), he restricted his model
>
>
>
> No mystery. Books in a library are hardly lost texts of Babylon. And
>
> he states his motivation plainly: "the possibility of eliminating
>
> nonsimple domains appears worth investigating!"
>
Without any objective reasons this seems to be a personal opinion to me. I don't object for all cases, but using a unchecked rule without considering potential alternatives is not a good thing.

>
> The model is not "restricted". It is *simplified*, a feature, not a
>
> bug. By showing -- more, *proving* -- that logical inferences could be
>
> drawn from data manipulated with a small number of operators closed
>
> over a domain, Codd released programmers from low-level complexity and
>
> man-centuries of work.
>
Codd shifted the complexity from one area to another. When dealing with n entities is replaced with n*x relations is a considerable increase in complexity. One reference told me that a SAP R3 system contains more than 100000 tables (one hundred thousand!). What about complexity?
>
>
> If you're programming a computer, graphs are a your natural ally
>
> because they can be mapped directly onto the computer's memory. They're
>
> of no use, though, when you want to manage data logically. How, for
>
> example, do you define a subset of a cyclic graph?
>
Depends on the subset definition. In our field of work we use a ordered list representation of graphs. A subset is a range of items satisfying same criterias.

>
>
> You're right to say that graphs are more complex than relations. It's a
>
> mistake, though, to conclude therefore that they are more powerful.
>
> It's been proved mathematically that graphs and relations are
>
> interchangeable in the sense that they can represent the same
>
> information. The difference is that relational theory is much
>
> simpler. That's its advantage, not a handicap.
>
It really a handicap. Try to express grouping and grouped aggregates in a frame with only "unordered sets". SQL deviates from the relational theory with implementing groups and grouped aggegats.
>

>
> OK, but it's not.
>
>
> Consider the UNIX filesystem, for instance, which you refered to
>
> earlier. Upon a time, when my mother wrote disk access routines for
>
> Univac, the programmer had to know all the particulars of the device,
>
> and read/write data in terms of the device's design. Unix
>
> revolutionized the field by abstracting all disk access into today's
>
> familar stream of bytes. No addresses, no heads or sectors or tracks.
>
> A catalog to facilitate sharing that anyone (potentially) can update,
>
> not just the system programmers. Works pretty good for nonrotating
>
> media, too, and over the network. And not an object in sight.
>
That depends on your object definition. For me a object is a data type with addition internal procedures, identity and means to communicate (signals, messages...) and can be implemented in various manors. Unix files fit in this description.

>
> ... I have long thought that
>
> stored procedures are to databases what methods are to objects, and
>
> subscribe to the idea that applications should access the data only
>
> through views and procedures.
>
Ok!

>
>
> Part of your critique is actually of DBMSs that we have, not of RM.
>
> SQL DBMSs largely support only a few primitive types that the user may
>
> then further constrain or write functions for. One cannot, for
>
> example, define an aggregate type as a set of columns, and use that
>
> name in, say, FK declarations. Nor can we usually define types of blobs
>
> and comparison functions for them (although I'm unconvinced that's a
>
> good idea).
>

On the contrary! My critic is on RM and not on the real SQL databases. My only critic on SQL is to pretend to be relational. My critic on RM can be summarized in the statement "relations are unordered sets". Any model based on a definition like "relations are sets with any (exploitable) sort order" is much better.

m.f.G.

Karl Scheurer Received on Mon Sep 02 2013 - 10:07:40 CEST