Re: We're doomed
Date: Sat, 28 Feb 2009 19:10:29 GMT
Message-ID: <F_fql.14306$Db2.2328_at_edtnps83>
Walter Mitty wrote:
> "Roy Hann" <specially_at_processed.almost.meat> wrote in message
> news:wIudnXcEAcEvjznUnZ2dnUVZ8uednZ2d_at_pipex.net...
>> Apart from our pension funds being shrunk to pocket change and >> stewing in a cloud of our own CO2, it seems relational databases >> are doomed too. >> >> http://www.readwriteweb.com/archives/is_the_relational_database_doomed.php?p=2 >> >> :-) >> >> -- >> Roy >>
>
> Just to take this seriously, if only for a brief moment, here is the
> proposition in a nutshell:
> "The responsibility of ensuring data integrity falls entirely to the
> application."
>
> Two points:
>
> First, this is the way things were before databases began to be used. If
> you go back to the 1960s, you'll find that nearly all applications were
> written exactly this way. It was the bug prone nature of this way of doing
> things that led to the rise of databases to begin with. My choice of the
> 1960s is arbitrary. In different local environments, the transition to
> databases happened much later, or never at all.
>
> Second, note that "the application" is singular. This way of doing business
> applies only when a database is embedded within a single application. If a
> database is an information nexus allowing multiple applications to provide
> and use shared information, the contracts between applications get drawn
> into the nexus itself. The author makes much of the supposed superior
> scalability of key/value data structures, but there is one way in which
> they scale very poorly: the transition from embedded in a single
> application to operating as a nexus between multiple applications.
>
> I guess I should acknowledge that majority of today's new databases are of
> the embedded type rather than of the nexus type. That means we fight most
> of the battles on the other side's turf. Maybe that provides an insight
> into how the keepers of the flame can survive the dark ages. I dunno.
That's the data perspective and no doubt the tacks of any progress are affected by the situations people find themselves in. But Codd's 1970 paper (I'd say it was the one that got the most attention) made its points with examples from 'singular' (if you will) apps and showed how a small set of operations had somewhat universal application when a certain logical organization for data was followed. One of the main consequences being that two different 'singular' apps should not invent their own database operations. As of today this has not occurred to many people on the 'dark side' even though they take it for granted that it's quite sensible to factor out all the operating system functions which the 1950's apps embedded.
By the early 1970's, some other fans were touting Codasyl doctrine for shared/'nexus' dbs. They had an 'enterprise' message (like so many of the so-called technology chatter these days, executive summary bumpf and so on) that dodged the nuts and bolts issues that Codd confronted head-on and he went out of his way to discount the use of network structures for such dbs, ie., they were almost as big a distraction and impediment to the sharing of data as the file systems they replaced, eg., needing just as much navigation. The recent Sara B post doted on another persistent distraction - the big dbms vendors are pre-occupied with concurrency, persistence, and hardware failure problems, not relational problems. In their turn, practitioners are pre-occupied with SQL problems and not relational problems. In other words, in the last fifty years very little attention has been paid to what I would call the pure application problems like inferencing and computation.
A no doubt minority attitude about concurrency is that while notable people like Jim Gray have described the problems concisely, most implementers confuse such descriptions with solutions. Here's another minority attitude - Codd's almost total emphasis on the database as the application of relational theory encouraged today's limited use of the theory. One could substitute relational notions for practically any of today's programming artifacts, eg., as Date implies, one could treat a machine language operator like '+' as a relation. An so and so on, relational theory potentially allows a specification language that is also executable (and machine transformable, eg optimizable), but has anyone here ever seen a relational schema that models the required concurrency for a given application? It is laughable how many people, such as the Entity-Relationship fans, took it for granted that the precision of RT needed to be superimposed with a specification language, especially one as fuzzy (and mostly irrelevant to apps) as E-R. XML is even more distracting. Taken to an extreme (which I think it should be), this attitude says that there is no such thing as a 'relational application' if that app uses a procedural/imperative language and/or limits its use of RT to persistency.
That's my little diatribe for today - basically I think most IT/CS progress has been derivative, plodding and over-sold and as usual in human affairs, very few people are willing to 'stretch the envelope' or 'step out of the box', which is what real progress always needs. Codd's invention remains reminiscent of the light bulb, the first efforts to manufacture it were overtaken when Edison realized that the missing ingredient was a power distribution system. Not to say I class Codd with the inventor of the faucet attachment for dispensing Mott's Clamato Juice! Received on Sat Feb 28 2009 - 20:10:29 CET