Re: Newbie question about db normalization theory: redundant keys OK?

On 14 Dec, 18:55, "Tony Rogerson" <tonyroger..._at_torver.net> wrote:
> "David Portas" <REMOVE_BEFORE_REPLYING_dpor..._at_acm.org> wrote in message
>
> news:1065f96a-1f8e-4fc7-b1cc-53137ebd8b8f_at_s8g2000prg.googlegroups.com...
>
> > You are saying that this is a distributed database but that it lacks a
> > mechanism for accurately propagating changes out to all its nodes?
>
> Nope - it's a normal database you have simply done a query against the
> database - the result of SELECT and then return to the database to validate
> your data against it - think about it; your insurance company posts you a
> claim form and you then send it back in - you need to validate what's on the
> form (our equiv of time table) against the database.
>

Then I don't see a problem. If the data is preserved only in one place then it only needs to be changed in one place. You said: "How do all the applications disconnected from the database now reach the record? They can't - the natural key has changed." which implied that the applications kept their own copy of the data (or at least had an earlier version of the key). Now you seem to be saying that no such copy exists. So how can the application be "disconnected"? Whatever the answer is, bad application design seems like a very poor excuse for compromising the data model. I suggest you fix the application instead.

> Also, please can you show me how you would simply put history in the table
> with celko's example.
>

I don't think there's any point. Joe's statement of the problem didn't indicate any need to preserve a history of changes. Assuming the requirement is to represent the current state then Joe's model is quite reasonable. Once you go beyond basic design principles, these design-by-newsgroup discussions always turn into futile tit-for-tat exchanges with a never ending string of "what ifs...". I've learnt to avoid them. I'd be happy to lend you D&D's book next time we meet up though.

--
David Portas