Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

Jan Hidders wrote:
>
> > I've often wondered what exactly *is* an XML-native solution. Is it
> > storing everything as text files?
>
> It can be. One of the better definitions is found at:
> http://www.rpbourret.com/xml/ProdsNative.htm

So, I read that page and it really left me with the feeling that I'm right to think that XML doesn't have anything interesting to contribute to the field of data management.

"At a minimum, the model must include elements, attributes, PCDATA, and document order."

This is completely oriented on XML syntax, and makes no mention of any least data management issue. (Well, maybe order.) Syntax is about the least important issue I can imagine.

What is the difference between an element and an attribute? Is it anything other than syntax, or just the result of the random happenstance of what was inherited from SGML? What does PCDATA have to do with anything?

Nowhere on the page did I find a single mention of a type system. How are we going to do data manegement without a type system?!

I think the idea of a programmable metamodel for data is a great idea, but I think that XML is just about the worst implementation I can imagine of such a model. To start with, I would expect a type system, some relationship mechanism beyond simple nesting, and a standardized way to specify schema, expressed in the metamodel itself (aka a data dictionary.) XML out the gate had none of these things, but I understand that there have been attempts to weld some of these features on after-the-fact.

As an engineer I am appalled at the various attempts to build something solid on this waxy foundation. Get the foundation right first, *then* build from there! Next time, let's please start with a type system.

> > So it is a renaissance of the network model?
>
> Well, if you want to call it that. But as I said, that name has all
> kinds of connotations that would not be justified. The data model would
> be more expressive. The constraint language would be very different. The
> query language would be very different. The update language would be
> very different. View definitions would be different. The way that
> queries would be optimized would be very different. Concurrency control
> would be different. These are not trivial things. They matter.

Do you mean all of these things relative to the network model, or to the relational model?

I'd be interested to hear what sort of specific things you'd like from a next-generation data model. I'll take a stab and guess that it includes union types; they're on my list as well. What sort of things would you like in, say, the constraint language that would be different? What about the update language?

> > Ok ... but I though half the point of OODBs was to lessen the "impedance
> > mismatch" between procedural OO programming languages and declarative
> > databases (by making the databases less declarative). What is the
> > motivation now?
>
> I'm not sure I understand. Whose motivation? For what?

I have often heard "lessening the impedance mismatch" cited as the motivating factor behind OODBMSs.

Marshall Received on Sat Jun 25 2005 - 07:53:03 CEST