Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Subtype PK Name


Subtype PK Name

Author
Message
barbararyan
barbararyan
Forum Newbie
Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)

Group: General Forum Members
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!
RBarryYoung
RBarryYoung
SSCrazy Eights
SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)

Group: General Forum Members
Points: 9456 Visits: 9517
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."
Grant Fritchey
Grant Fritchey
SSCoach
SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)

Group: General Forum Members
Points: 17647 Visits: 32270
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 Query Performance Tuning and SQL Server Execution Plans
Product Evangelist for Red Gate Software
RBarryYoung
RBarryYoung
SSCrazy Eights
SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)

Group: General Forum Members
Points: 9456 Visits: 9517
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."
Jack Corbett
  Jack Corbett
SSChampion
SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)

Group: General Forum Members
Points: 11054 Visits: 14858
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
At best you can say that one job may be more secure than another, but total job security is an illusion. -- Rod at work

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
timothyawiseman
timothyawiseman
SSC Eights!
SSC Eights! (806 reputation)SSC Eights! (806 reputation)SSC Eights! (806 reputation)SSC Eights! (806 reputation)SSC Eights! (806 reputation)SSC Eights! (806 reputation)SSC Eights! (806 reputation)SSC Eights! (806 reputation)

Group: General Forum Members
Points: 806 Visits: 920
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/
Grant Fritchey
Grant Fritchey
SSCoach
SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)

Group: General Forum Members
Points: 17647 Visits: 32270
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 Query Performance Tuning and SQL Server Execution Plans
Product Evangelist for Red Gate Software
barbararyan
barbararyan
Forum Newbie
Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)

Group: General Forum Members
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?
Grant Fritchey
Grant Fritchey
SSCoach
SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)

Group: General Forum Members
Points: 17647 Visits: 32270
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 Query Performance Tuning and SQL Server Execution Plans
Product Evangelist for Red Gate Software
timothyawiseman
timothyawiseman
SSC Eights!
SSC Eights! (806 reputation)SSC Eights! (806 reputation)SSC Eights! (806 reputation)SSC Eights! (806 reputation)SSC Eights! (806 reputation)SSC Eights! (806 reputation)SSC Eights! (806 reputation)SSC Eights! (806 reputation)

Group: General Forum Members
Points: 806 Visits: 920
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/
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search