January 21, 2009 at 3:46 pm
I have a supertype table "Persons" (PK - "PersonID") and several subtype tables. Is it necessary/mandatory to name the PK of all the subtype tables "PersonID"?
One of the subtype tables is "Employees". I want to use "EmployeeID" as the PK (i.e., PersonID in Persons is related 1-1 to EmployeeID in Employees).
Thanks!
January 21, 2009 at 3:59 pm
barbararyan (1/21/2009)
Is it necessary/mandatory to name the PK of all the subtype tables "PersonID"?
Necessary? No.
Mandatory? No.
A really good idea? Yes.
[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]
January 22, 2009 at 5:45 am
I've done it both ways and either will work, but in the long run, keeping the PK name the same throughout the structure seems to lead to less confusion.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 22, 2009 at 6:34 am
Exactly, Grant.
The general rule of thumb that you want to follow is: if columns in two different tables hold the same values and are intended to match each other then you should give them the same name. This makes life so much easier later on.
[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]
January 22, 2009 at 8:23 am
RBarryYoung (1/22/2009)
Exactly, Grant.The general rule of thumb that you want to follow is: if columns in two different tables hold the same values and are intended to match each other then you should give them the same name. This makes life so much easier later on.
Exactly my opinion. I don't want to have to dig into the relationships to find out which column(s) I should be joining on.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
January 22, 2009 at 3:15 pm
I'll agree with Grant, though there are some cases where it makes sense to have a column named Id in the base table and then the foreign keys referencing it may be named BasetablenameId.
In general, it should be very obvious through names alone what the relations are.
---
Timothy A Wiseman
SQL Blog: http://timothyawiseman.wordpress.com/
January 23, 2009 at 6:09 am
timothyawiseman (1/22/2009)
I'll agree with Grant, though there are some cases where it makes sense to have a column named Id in the base table and then the foreign keys referencing it may be named BasetablenameId.In general, it should be very obvious through names alone what the relations are.
I've seen those designs. I've never been crazy about them. If you query more than one table and want to return the PK you then have to alias the PK names in the queries... It seems really sloppy to me. Worse yet, it requires extra work and I am lazy.
I prefer naming something what it is and letting that thing live that way through the database and, if possible, throughout the enterprise.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 23, 2009 at 6:36 am
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.
Does this make sense?
January 23, 2009 at 7:06 am
Sure, it makes sense. It even works well a good percentage of the time. There's still that disconnect between Person & Employee that has to be documented and explained to everyone coming in. Also, if you have an identity column in most places but that PK won't behave that way.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 23, 2009 at 11:57 am
Grant Fritchey (1/23/2009)
timothyawiseman (1/22/2009)
I'll agree with Grant, though there are some cases where it makes sense to have a column named Id in the base table and then the foreign keys referencing it may be named BasetablenameId.In general, it should be very obvious through names alone what the relations are.
I've seen those designs. I've never been crazy about them. If you query more than one table and want to return the PK you then have to alias the PK names in the queries... It seems really sloppy to me. Worse yet, it requires extra work and I am lazy.
I prefer naming something what it is and letting that thing live that way through the database and, if possible, throughout the enterprise.
You have a good point, but it makes for consistency in the naming of the primary key and that can make certain things easier, especially when working with certain 3rd party tools for Linq.
---
Timothy A Wiseman
SQL Blog: http://timothyawiseman.wordpress.com/
January 23, 2009 at 8:21 pm
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]
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply