Re: Database design, Keys and some other things

dawn wrote:
> ...If you are going to model Cars, then model Cars.
and
>... If you are going to model a Person, then model a Person. and
> To the extent feasible, I would suggest modeling real world entities as
> whole at the outset. A person in the real world would be modeled by a
> row in the Person table. A Car in the real world would be modeled by a
> row in the Car table. Feel free at the start of your modeling to add
> properties that are lists to an entity (car colors, for example).
>
> Then you can move to 1NF if needed for the target implementation. A
> Car might be referenced in multiple CarColor rows after you split out
> the list properties. Similarly, a Person might have a list of former
> names, but stay the same person. So, you do not want two PersonKeys
> for this one person.

He forgot "state" - but this will have multiple consequences/lead to re-edits in his later remarks.

> This design issue might have a real name, but I think of it as doing a
> "1NF in place" rather than splitting out new tables for list
> properties. You start with a car and then you realize it has at least
> one multivalued property, so you distort your Car table to a
> CarProperty relationship table, losing the model for Car in the
> process. --dawn

When are you coming to the Netherlands? :-) Received on Sun Sep 25 2005 - 00:45:03 CEST