Question

I’m looking at this company’s database design, and would like to know the purpose of their design, ie store relationship in one table and the data in another, why do this?

They have this,

EMPLOYEE

• Id (PK)
• DepartmentId

EMPLOYEE_DATA

• EmployeeId (PK)
• First Name
• Last Name
• Position
• etc…

---

Rather than this…

EMPLOYEE

• Id (PK)
• DepartmentId
• First Name
• Last Name
• Position
• etc…

…OR this…(employee can belong to many departments)

EMPLOYEE

• Id (PK)
• First Name
• Last Name
• etc…

EMPLOYEE_DEPARTMENT

• Id
• EmployeeId
• DepartmentId
• Position

Answer 1

Purpose of design is determined by business rules.
Business rules dictate entity (logical model perspective) / table (physical model perspective) design. No design is "bad" if it is built according to the requirements that were determined based on business rules. Those rules can however change over time — foreseeing such changes and building to accommodate/future-proof the data model can really save time, effort and ultimately money.

The first and third example are the same — the third example has an extraneous column (EMPLOYEE_DEPARTMENT.id). ORMs don’t like composite keys, so a single column is used in place of.

The second example is fine if:

• employees will never work for more than one department
• there’s no need for historical department tracking

Conclusion:

The first/third example is more realistic for the majority of real-world situations, and can be easily customized to provide more value without major impact (re-writing entire table structure). It uses what is most commonly referred to as a many-to-many relationship to allow many employees to relate to many departments.