Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]
Date: 25 Jun 2005 11:00:35 -0700
Jan Hidders wrote:
> Marshall Spight wrote:
> >>It can be. One of the better definitions is found at:
> > 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. :-)
> 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 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.
> 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.
Still very curious,
Marshall Received on Sat Jun 25 2005 - 20:00:35 CEST