best table layouts with SSNs?

R

ryannick

I'm creating a database for employees and need to include a lot of fields for
each people and can't figure if the best way to do that is one or more
tables. Now have one that includes employment status, job title, social
security number as the PK, and a couple other fields.

I started a table that will include whether or not their file includes the
required forms and signatures with a yes/no check box for each one. I want
the SSN to be the identifier for each and in order of last name.

Better to have one table with lots of fields or two and try to figure out
how to link them and not have to input SSNs and names twice?
 
K

KARL DEWEY

With privacy issues the way they are it is best not to use SSN's but suggest
that the organization develop an EmployeeCode.
The main table for the employee would have all data that would not change -
birthdate, address, home phone, office phone, etc.
Other information is subject to changes and a record of the change
maintained - update, employment status, job title, etc.
 
P

peregenem

KARL said:
The main table for the employee would have all data that would not change -
birthdate, address, home phone, office phone, etc.
Click to expand...

'birthdate' would change only rarely (keying error, witness protection
order, etc) but the others could change faiely frequently for even a
small organization.

There are no standard answers. If they are attributes of an 'employee
entity' then they should in the Personnel table. However, it sounds to
me that has_signature is an attribute of an 'official document' entity
and should be modelled in a separate table. Because more than one
'employee' could have more than one 'official document' then a
relationship table (a.k.a. junction table, lookup table, etc) may be
appropriate. I am guessing here, of course...
 
Top