Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Subtype PK Name Expand / Collapse
Author
Message
Posted Friday, January 23, 2009 8:21 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Thursday, June 5, 2014 10:54 AM
Points: 9,902, Visits: 9,480
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.


-- RBarryYoung, (302)375-0451 blog: MovingSQL.com, Twitter: @RBarryYoung
Proactive Performance Solutions, Inc.
"Performance is our middle name."
Post #642903
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse