Ciprian Trofin writes:
>Basically I have some tables with only 2 fields (ID and name), and a
>central table, joined by a one-to-many relation. The key point here are the
>2-field tables. If I keep them separate, I can extend them (add new fields)
>without problem when need arise. But if there is no
Carsten,
Thanks for the answer (and other thanks go to the other guys that answered
me).
I think normalization is the way to go. I think it is the right thing to
do (in theory). The problem is that theory doesn't fit all.
Basically I have some tables with only 2 fields (ID and name), and a
centr
>Cities (CityID, Name)
>People (PersonID, Name)
>Travel_Exp (ExpID, Date, PersonID, Per_Diem)
>Travel_Exp_Cities (CityID, ExpID)
Based on the descriptions I'd tend to go with a normalized table set
of this nature:
Cities (CityID, Name)
People (PersonID, Name)
Travel_Exp (ExpID, Date, PersonID, Ci
Carsten R. Dreesbach [mailto:[EMAIL PROTECTED]
Sent: 09 April 2004 00:52
To: Ciprian Trofin
Cc: [EMAIL PROTECTED]
Subject: Re: Best practice on table design
Hi Ciprian,
OK, I'm by no means a DB guru, so a) take this with a grain of salt
and b) feel free to tear it apart if I'm completely
Hi Ciprian,
OK, I'm by no means a DB guru, so a) take this with a grain of salt
and b) feel free to tear it apart if I'm completely wrong! ;]
If in fact your people and city tables aren't going to change very
often, then why don't you just go all the way and keep that
informatio
