Jim Starkey napsal(a):

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

Which I find invaluable :-) This experience is hard to get these days,
nor any really good literature about these topics.

> Based on this experience, I've reached the following conclusions:
>
> * All navigational DMLs are disasters

I wouldn't call them smashing success either, but could you be more
elaborate on this? Was the problem in language itself or in
implementation or background engine? Was the primary problem the
flexibility or performance?
That really interest me, because for example the data manipulation needs
of whole AI world is more close to navigational DML than relational, so
calling them a disaster doesn't resonate well in my ears.

> * OO doesn't translate to persistent objects

Indeed.

> * The object database guys should have known better but made the
> same mistakes as the CODASYL guys

What mistakes do you mean?

> * Relational DML is a excellent compromise between flexibility and
> performance

Certainly, no doubt about that. The problem is that it lefts some very
hard problems on developer's shoulders pushing them away to upper levels.

> * SQL is a lousy relational language but a better one isn't worth
> the effort (sorry, GDML)

That's unfortunate truth.

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

Very good idea.

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

I'm not all that convinced that it would help anything. It would IMHO
just complicate the system and give to developers more ammunition to
shoot themselves down.

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

This itself will definitely make Nimbus worth trying (and the whole
cloud thingy is a nice bonus). I guess that if we can't really fix
relational model now, we could at least try to make it even more simple
and usable, so it wouldn't get into our way all that much.

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

Understandable. There is no room for half-way solutions in the
marketplace. You can succeed with something completely different or
basically the same, but nothing in between. Different relational DML is
not different enough.

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

I wouldn't even try to convince you to use something different than
relational model for Nimbus. It would make much sense from business POV,
thought, at least at this point. I guess that solving the cloud issues
and "dumbing" the type system down would keep you busy enough to even
consider putting another hard nut to crack on plate. Copying older
approaches (i.e. hierarchical, network or even object) seems not very
smart, and new ones are too raw and would need some time to take shape.
To get something new along these lines into Nimbus would need more
research, inventions and testing, no ready to use blueprints, which
would push the release far to future. But so far I see Nimbus as very
promising piece of technology that could be eventually used as vehicle
to deliver something new once it would be clear how this "something"
would really look like :-)

best regards
Pavel Cisar
IBPhoenix