Re: I have read tons of theory...but still...one question

"Kostas" <noemail_at_noemail.net> wrote in message news:10mvu879vgdp0c_at_corp.supernews.com...
> Thank you for your informative answers. I read them all very carefully and
I
> understand what you are saying. It is interesting for me to see that the
> second design was logically a worse choice because I thought from a couple
> of example cases I had found that this is the theoretical preferred
design.

I would consider it a better design too even if your table of phone types holds exactly the full list of valid phone types. By adding this table, you hare adding a validation table to the database that could be (in theory) maintained by a user. There are (at least) three places to put the validation options for your phone type -- encoded in database constraints, in a validation table such as the one you designed, or in the application logic (such as the GUI validation). For any validation values where it is not fixed exactly what these values must be (Male/Female comes to mind as an exception), it is best to hold them in a table. That is not a normalization issue, however, but definitely one related to maintainability.

> 1. I used the PhoneType entity because I was concerned for string errors
of
> the type "Cellular" vs. "Celular" and so forth, whereas if those values
were
> to be fixed a-priori in a separate table this wouldn't occur.
>
> 2. As for using phoneID as an identifier instead of the actual phone
number,
> I did it because I read articles on the debate of semantic vs. artificial
> identifiers and again got the impression that artificial poses less
threats
> to the development of a database.

Lots of opinions on this one. One question to ask is whether you would ever want to keep this row of data and yet have the phone number change. There is simply not enough important data to keep if you decide you need to change the phone number -- then delete this one and add the new one. So, I agree with those who said that the phone number on its own could be the ey. --dawn

<snip> Received on Fri Oct 15 2004 - 23:35:16 CEST