Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]
Date: Tue, 28 Jun 2005 20:27:36 GMT
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. :-) Unnecessary complications are the enemy of the theorist. They make his/her work less pleasant and the chances of finding something interesting and useful much smaller.
>>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.
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?
>>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'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?
- Jan Hidders