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

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

> Oh yes. Everything you mention above is in there, including key
> constraints. The typing system is also very elaborate, it even allows
> you to define certains sets of strings described by regular expression
> as strings, and is user-extensible.

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.

> 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? I don't see how you can get away with not picking one and still having the generality you get if you do pick one.

> 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? I feel that one problem with SQL is that the keys are often integers, which they really shouldn't
be since it doesn't make sense to add and subtract keys.

> 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 Tue Jun 28 2005 - 16:56:05 CEST