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
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
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,
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
Hello,
I have the following structure:
people
-
| id | name |
-
| 1 | John |
| 2 | Mary |
-
cities
| id | city|
| 1 | Glasgow |
| 2 | Madrid |
| 3 | Berlin |
travel_expenditures
