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

Jan Hidders wrote:
> Marshall Spight wrote:
> >>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.
>
> It contributes new problems that weren't there before. :-)

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

What kind of things make it interesting to you?

> > What is the difference between an element and an attribute?
>
> Elements are ordered, attributes are not. Elements can contain complex
> content, attributes only strings.

How is this a useful distinction? It seems that everything you can do with attributes you can do with elements. How does the distinction between elements and attributes help me solve my data management problems? (Or is this question not appropriate?)

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

I'm not clear what it would mean for a DBMS to work with data without a schema. Just store one big blob? That doesn't seem like it meets the "M" part of "DBMS." How do you manage integrity with no schema? How do you get any semantics?

> > [...] 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 XML Schema is represented as XML, then? Is there an XML schema for XML schema? Does it let you specify, say, ints and strings and floats? What about product or sum types? Does it allow the specification of foreign keys or some other way of doing many-to-many relationships?

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

Does this mean that you'd like to be able to specify, say, two different entities and separately the cardinality relationship between them? Has anyone attempted this? It seems an intruguing approach.

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

Is this only an implementation issue, or are there logical/interface issues here as well? Offhand it seems that allowing nested relations would meet this requirement, at least the logical part.

Still very curious,

Marshall Received on Sat Jun 25 2005 - 20:00:35 CEST