Re: Table design question

OK - 2nd form of table now needs to "relate" to another table... Do you really want to "join" on fname, mname, lname to the second table? Carrying all 60 bytes in that (all) table(s) as well as the staff table? Or, would you rather join on a integer field ( 4 bytes as in the 1st form of the table)? Also, say that the staff person is a woman, gets married, and takes on the husbands sirname ( this does happen occassionally ). (1) do you want to programmatically handle keeping both (all) tables that have some relation to the staff table in sync? (2) what about historical data (offline storage)? Do you want to lose that "fact" that these two names are infact the same individual? I think you can gather my take on this one... Disclaimer: The above thoughts, ideas, or opinions are mine and mine alone... besides, I'm not sure anyone else would want to claim them! Eric P. Melillo Sr. Database Administrator Associated Grocers, Inc. 3301 South Norfolk Seattle, WA 98118 vmail: (206) 767-8178 email: eric_melillo@agsea.com "Don Pritchard" <please_reply@newsgroup.com> on 03/19/99 05:11:55 AM Please respond to "Don Pritchard" <please_reply@newsgroup.com> To: informix-list@iiug.org cc: (bcc: Eric Melillo/AGInc) Subject: Table design question Hi All I've always battled against this one : If you were creating a staff table Would you have the following staff_id serial fname char(20) mname char(20) lname char(20) .. .. .. where obviously staff_id is the primary key *or* fname char(20) mname char(20) lname char(20) .. .. .. Where the primary key is a combo of the first 3 fields The second is a bigger index but it dispenses with a code field. Any thoughts? Thanks.