One table or two?

[Joe Holzhauer]

I'm designing an employee evaluation program. Most of the items being
evaluated at rated as either Satisfactory or Unsatisfactory (e.g. Employee
is punctual), but a few are free comments (e.g. Areas for improvement).
Should I keep one tblRatings and have an unused boolean or memo in each
record, or should I split it into tblSU_Ratings & tblCommentRatings? What
do you think?

 

[John Vinson]

I'm designing an employee evaluation program. Most of the items being
evaluated at rated as either Satisfactory or Unsatisfactory (e.g. Employee
is punctual), but a few are free comments (e.g. Areas for improvement).
Should I keep one tblRatings and have an unused boolean or memo in each
record, or should I split it into tblSU_Ratings & tblCommentRatings? What
do you think?

Three tables, I'd say:

Employees
EmployeeID
<all the usual person table stuff>

RatingCategories
CategoryID
Category <e.g. "punctuality", "technical ability">

Ratings
EmployeeID
CategoryID
Satisfactory <yes/no>
Comment <memo>

You've got a classic many (employees) to many (ratings) relationship;
model it as such.

John W. Vinson[MVP]

 

[kasab]

As a general rule of thumb, if fields relate to only one topic (entity), then
keep those fields in the same table. I am guessing that the important
concepts here are "employee" and "evaluation" in which case you will make it
easier if you have both boolean and memo in the one table.

HTH