>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, CityID, Exp)
This provides consistent use of person and city. Along with gathering
related data into the same record. It is doubtful that an expense would
reference more than one person or city. Normalizing to this table set
provides a simple means of querying related data, without undue duplication
of data elements with the possibility of errors creeping in during the
data input. But these observations are based upon my own common sense
view of the kinds of business rules/processes that are likely to be used.
If your business processes would not follow the described mechanisms, say
you do indeed share travel_expenses between individuals, or the expense
can be across cities, the normalization I've described would not fit.
Brad Eacker ([EMAIL PROTECTED])
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
