Pavel Cisar wrote:

> Jim Starkey napsal(a):
>
>> No, Paul, I think we're being radically creative. At least that's my
>> intention. A cloud is a new platform that requires new solutions and a
>> new way of thinking. Time to give poor Mr. Darwin a rest and take a big
>> leap (though the famous scene from "Butch Cassidy and the Sundance Kid"
>> does come to mind).
>>
>
> That's very encouraging to hear, as I agree that we're at the beginning
> of new era in data management. But although it's nice to see you
> involved in an attempt to initiate the big leap in data management
> technology, I'm a little bit disappointed in what direction you're going
> as taking your track record into account, I thought that you would be
> more "radical" in creativity. It seems that while Nimbus puts in rest
> some historical baggage (which is all good and nice), it still follows
> the "old" school of data management, just reincarnated for modern
> hardware and scalability needs. Don't take me wrong, that's all great,
> nice and much needed, but really not much exciting.
>
> You wrote: "I believe that the relational model has passed the test of
> time and is organization of choice, other things being equal. The
> hierarchical, network (CODASYL), and "object oriented" database have all
> died while relational systems have thrived. The issue is not the model
> (though I prefer semantic extensions) but the implementation."
>
> You're correct in your observation, but that doesn't validate the
> relational model as the right one for future. In fact, the relational
> thinking and the necessity to provide relational SQL layer on top of any
> "new" design to just satisfy current developer's habits and market
> expectations or desperate attempts to graft any new design/model on top
> of relational model is the biggest obstacle to such big evolutionary leap.
>
> The main problem with the relational model is that we're at the verge of
> handling complex models described by huge and complex semantic
> definitions and introduction of ontologies into standard data management
> that relational model (even if we would dump SQL with it's closed world
> assumption for good) can't handle sufficiently even with sophisticated
> semantic extensions.
>
> The second problem of relational model (which is in fact more or less
> common problem of all current data management technologies, Nimbus
> included) is that's designed to work best with "basic" (or at least
> limited set of) data types (that are then formed into relations,
> classes, whatever) we all know and use for ages (although with
> occasional extension or improvement to make it worse), while it's
> starting to be clear that we need a better way to represent/encode
> information in our data stores (hint: unified recursive class/type
> definition and composition). Not to mention the necessity to have better
> query language than that bloated yet incomplete fossil called SQL. But
> inertia is a b*tch.
>
> The irony is that it seems that the network (CODASYL) model is more
> close to our current and future needs that relational ever would be.
> Certainly it has to be taken to modern age of RDF/OWL and LinkedData,
> but it still seems to be better starting point for implementation design
> than relations (but I love to be proved wrong here). Combine it with
> power of implementation as cloud & grid hybrid (pure cloud is not
> enough), make it open for everybody to get it adopted (a real show
> stopper, I know) to power the semantic web revolution in age where
> desktop and net melts into one colorful mashup, and then you would
> really have *something* and ground breaking. In fact, a real Google killer.
>
> But don't take me too seriously, as I'm known to be a victim of cross
> discipline studies which means that I really don't know a thing about
> anything :-) I also realize that although Nimbus is not so ground
> breaking, it's innovative enough to be very useful and more than well
> marketable.
>

You raise some interesting points well worth discussing at length. I
certainly can't prove that the relational/semantic model is the best
possible data model, nor would I want to try. I do have some experience
with alternatives, however:

* In my extreme youth, I worked on what became CCA's Model 204, an
amorphous data model were every record was an arbitrary set of
attribute/value pairs
* A few years later I worked on the ArpaNET Datacomputer, which used
a hierarchical data model
* After a bait-and-switch are DEC, I spent a year porting the
CODASYL IDMS to the PDP-11.
* I implemented Rdb/ELN, Interbase, and Netfrastructure/Falcon, all
relational systems.
* I watched Ontologic then ObjectDesign, both OO database companies,
very closely
* I wrote (and buried) an object-relational mapping product that
generated COM objects
* I've written nothing but structured OO code for over a decade
* I've implement two object cluster serialization technologies, once
for C++ and one for Java

Based on this experience, I've reached the following conclusions:

* All navigational DMLs are disasters
* OO doesn't translate to persistent objects
* The object database guys should have known better but made the
same mistakes as the CODASYL guys
* Relational DML is a excellent compromise between flexibility and
performance
* SQL is a lousy relational language but a better one isn't worth
the effort (sorry, GDML)

I'm inclined to keep SQL DML but offer a number of procedures wrappers
to support a single exchange aggregating interface. One wrapper will
probably return XML and another a serialized object stream.

The basic relation model needs extension to handle type hierarchies. It
would also be nice to support an object serialization with invocable
methods to handle very complex types. But I believe the basic model is
solid, needing only judicious upgrading (like getting rid of char,
varchar, and clobs in favor of text , ints of all sizes in favor of
number, and varbinary and blobs in favor of bytes).

We could do better than SQL, but not much better, and only at the cost
of a great deal of resistance. I made my peace with SQL years ago.

I'm perfectly willing to bounce around alternatives to either the
relational data model or the SQL language and even, if necessary, to
change my mind. At the moment, however, I don't see any better
choices. There may be, of course, so if you disagree, give us a pointer.

--
James A. Starkey
President, NimbusDB, Inc.
978 526-1376



[Non-text portions of this message have been removed]