barbararyan (1/23/2009)
The supertype table Persons has several "child" tables containing information (e.g., contact information) that applies to all "persons" -- both employees and non-employees.However, subtype table Employees has several "child" tables (e.g., EmployeeTime, EmployeeCertifications, EmployeeTraining, etc.) When creating views, etc. which include these tables, it seems more straightforward/self-documenting to join on "EmployeeID" vs. "PersonID", since the join is on the Employees table and NOT the Persons table.
Nah. Not only should a column have the same name, no matter what table it is duplicated in, but Identity columns should also be named for the table/entity that defines them. That way you can find them.
Thus, your PersonID columns should be named "PersonID" everywhere. Anyone else coming into your DB who sees "EmployeeID" in an Employee table is going to naturally (and rightfully) assume it is that table's Identity column, even though it is not.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]