Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]
Date: 29 Jun 2005 10:31:41 -0700
Jan Hidders wrote:
> Marshall Spight wrote:
> > [coalescing two messages.]
> > Jan Hidders wrote:
> >>Marshall Spight wrote:
> >>Me personally? It raises all kinds of new and intricate research
> >>questions that seem mathematically challenging. That doesn't mean that I
> >>don't think XML is practically useful, on the contrary, but this is what
> >>primarily fascinates me about it.
> > Hmmm. I detect a hint of "I like it because it's complicated."
> > That concerns me.
> Well, you just will have to trust me on that one. :-)
Okay, I trust you.
> > Does that mean it's not statically typed? I don't see how you
> > could statically type whether a string belonged to a regular
> > expression or not, at least not if you wanted to have regular
> > strings be assignable at runtime.
> The typing system is essentially a named typing scheme, so the user
> defines the subtype relationship (which can be checked statically).
> >>Let me mention two small things. In the RM if you want to add a
> >>one-to-many relationship between two entities you have to extend one of
> >>the relations with a foreign key. If there are more than one candidate
> >>key you have to choose one of them. In an ER model you don't have to
> >>make such a choice, you simply indicate that there is a relationship.
> > Uh, how is that going to work? If I have a user id and an email
> > address as keys, and some user-level detail data (specified as
> > many-to-one with users) and I don't specify a key, what happens
> > when I change the email address key?
> Then you change the email addres of this user. Why do you think that is
> a problem?
Because you didn't specify how the detail info joins to the master record. And now we've changed the master record in one out of the two ways we have to identify the master. Which one does the detail consider definitive? It seems like it has to be one or the other, unless you are going to introduce the idea that rows have identity as well as value. You're not going to do that, are you? Think of the children!
> >>Another small thing is updating primary keys. If a primary key has
> >>accidentally been entered wrong and you want to fix that with an update
> >>then it is usually not possible to simply update it, and the problem
> >>gets even worse if it is also refered to by foreign keys. In an ER model
> >>this is a non-problem.
> > Would these issue be solved with opaque keys?
> Yes, that is at the core of my suggestion: a decent theoretical
> foundation for opaque keys, abstract identifiers, or whatever you want
> to call them.
> >>I basically have the FDM data model in mind, but modernized a bit.
> > I'd like to read more about this. It seems like there are some acm
> > papers on this; I can try to get some of them. Any favorites?
Marshall Received on Wed Jun 29 2005 - 19:31:41 CEST