Besides, every table should have an id field. From a maintenance standpoint alone, it makes things much easier. I recently designed a database system for Jury Tracking. In my Juror Table, each juror has a unique id (couldn't use the SSN because people can be summoned repeatedly). Within this table, there is a field StatusID. This is tied to the Status Table:
1 = Will Serve
2 = Postponed
3 = Excused Medical
etc.
If I stored the entire description of the status in the Juror Table instead of just the code, when the users came back to me 6 months later and say "We want Postponed change to Postponement" instead of having to write a query to update all the records, all you have to do is go to Status Table and change the description.
This design also allows you to control what values can be stored in that field (by enforcing referential integrity). If I allowed the user to type in each status code, that field may be filled with:
Wil serve
Will Server
WS
Will Serve
which makes report generation a NIGHTMARE! So instead of having to come up with every variation of status code a user can come up with, I only have to search for jurors whose status code matches a specific number.
For this and the above stated reasons, I would suggest not getting rid of the id field.
Leslie
landrews@metrocourt.state.nm.us
There are 10 types of people in the world -
those who understand binary
and
those who don't!