OK, a quick question of of style over substance here.

I have a database that someone else designed (very, very badly) and I'm trying to redesign it into something approaching a real db structure. Now, one table is called 'StaffMasterFile' and contains fields to do with the staff members (StaffID, names, network login etc), I also have another table called EmploymentStatus which contains data about current role, telephone number, desk ID, department and so on for each employee (foreign key on StaffID into StaffMasterFile). Currently there is a one-to-one mapping between the two tables because there is no history in the EmploymentStatus table.

I'm wondering whether to combine the two tables into one wider table, or two maintain two separate tables in case someone decides that recording historical employment info would be a good idea. Murphy's law implies that if I merge them then the requirement for history will materialise, but if I leave them separated it's an unecessary overhead in the database.

your thoughts, please

Chris


There are two secrets to success in this world:
1. Never tell everything you know

__________________
There are two secrets to success in this world:
1. Never tell everything you know

IMO if thee is a one to one relationship, yes merge them. What I mean by this:

;;;EmploymentStatus which contains data about current role, telephone number, desk ID, department

If each person has one current role, one telehone number (you may place several ph fields when you merge them, MB, HM, FAX etc), one desk etc... Yes merge them

;;;Murphy's law implies that if I merge them then the requirement for history will materialise

This is fine, have a one to many relationship between the StaffMasterFile table and a new table EG StaffHistory.

Wind is your friend
Matt