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

Marshall Spight wrote:
> 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

It contributes new problems that weren't there before. :-) But seriously, who claimed that XML would be a better way to model your data? I certainly wouldn't. But it's an interesting and important data exchange format, and its widespread use will inevitably lead to the need to manage data that is in that format. That's all.

Also note, btw., that a Real RDBMS that allows you to define a domain that captures all the aspects of an XML document as described in the definition, would pretty much satisfy the definition.

> What is the difference between an element and an attribute?

Elements are ordered, attributes are not. Elements can contain complex content, attributes only strings.

> 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?!

Sometimes you will have a schema for your XLM documents, sometimes you won't. The DBMS should be able to deal with both situations.

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

Yep. XML Schema does all that. It's a bit, er, bulky, though.

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

I meant the network 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?

I think I would first concentrate on the global structure of the data model, the associated languages depend on that. Here I have two big wishes: 1. I want a data model that is at an abstraction level that is comparable to the Entity-Relationship Model. 2. I want a data model that is completely unbiased wrt. how data is nested. I don't want a distinction like between the relational engine and the domain/type engine. When the domains get big and complex and queries combine data from different levels, then such a separation will make query optimization unncessarily difficult.

• Jan Hidders