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 Wednesday, January 21, 2009 3:46 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Saturday, October 31, 2009 9:07 AM
Points: 9, Visits: 39
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!
Post #641228
Posted Wednesday, January 21, 2009 3:59 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/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.


-- RBarryYoung, (302)375-0451 blog: MovingSQL.com, Twitter: @RBarryYoung
Proactive Performance Solutions, Inc.
"Performance is our middle name."
Post #641234
Posted Thursday, January 22, 2009 5:45 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Yesterday @ 7:49 AM
Points: 15,713, Visits: 28,120
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
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #641575
Posted Thursday, January 22, 2009 6:34 AM


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
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.


-- RBarryYoung, (302)375-0451 blog: MovingSQL.com, Twitter: @RBarryYoung
Proactive Performance Solutions, Inc.
"Performance is our middle name."
Post #641638
Posted Thursday, January 22, 2009 8:23 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Friday, September 12, 2014 1:29 PM
Points: 11,286, Visits: 13,072
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

Applications Developer

Don't let the good be the enemy of the best. -- Paul Fleming

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
How to Post Performance Problems
Crosstabs and Pivots or How to turn rows into columns Part 1
Crosstabs and Pivots or How to turn rows into columns Part 2
Post #641755
Posted Thursday, January 22, 2009 3:15 PM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Friday, April 4, 2014 4:40 PM
Points: 751, Visits: 917
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/
Post #642136
Posted Friday, January 23, 2009 6:09 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Yesterday @ 7:49 AM
Points: 15,713, Visits: 28,120
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
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #642399
Posted Friday, January 23, 2009 6:36 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Saturday, October 31, 2009 9:07 AM
Points: 9, Visits: 39
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?
Post #642417
Posted Friday, January 23, 2009 7:06 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Yesterday @ 7:49 AM
Points: 15,713, Visits: 28,120
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
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #642439
Posted Friday, January 23, 2009 11:57 AM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Friday, April 4, 2014 4:40 PM
Points: 751, Visits: 917
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/
Post #642686
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse