• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 274
  • Last Modified:

SQL Self Join PK on PK?

I'm looking at database in Sql Mgmt Studio in a database diagram and noticed one table which self joins on it's PK (PK -> PK). The PK is never used again to link another table, although it does contain foriegn keys which  other tables link to it.

Q. Why did the former db dev so this?
2 Solutions
Why did the former db dev so this?

This is a tough one!
Anthony PerkinsCommented:
I agree.  This is pure conjecture on my part, bu I suspect a "recursive" table.  For example, a table of employees where one employee reports to someone who in turn reports to someone else and all the way up the food chain.
Deepak ChauhanSQL Server DBACommented:
Primary key is not only just to link another table.  

It can either be a normal attribute that is guaranteed to be unique. When you specify a PRIMARY KEY constraint for a table, by default a clustered index is created for the primary key columns. This index also permits fast access to data when the primary key is used in queries. So this can be use to avoid NULL values, Duplicate values.
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

WorknHardrAuthor Commented:
I understand a self-join table where a PK links to a FK. For example, unlimited Parent-Child row data for a treeview. I've also read about speeding-up self-reference queries. I'm guessing its a fix instead of good solution.
Kent OlsenData Warehouse Architect / DBACommented:
For this to make a lot of sense, there needs to be a relationship between two (or more) rows that can be satisfied by the primary key.

Manger/Employee doesn't fit this well as there can be an arbitrary number of employees per manager and each manager can be one of an arbitrary number of employees that report to a higher level manager.  This is best solved by an additional column with the primary key of the row's manager.

Invoices have the same general behavior in that the number of items that make up the invoice is typically arbitrary.

Inventory, assembly, etc.  all fall into this category.

So the key is understanding the data in the table.  It could be that the data is paired by consecutive ID values (0,1), (2, 3), (4, 5), etc.

  SELECT * FROM t as t0
  INNER JOIN t as t1 ON t0.id / 2 = t1.id / 2;

It could be that the data is static and that the PK relationship is a binary tree.

  SELECT * FROM t as parent
  LEFT JOIN t as lchild on parent.id *2 = lchild.id
  LEFT JOIN t as rchild on parent.id * 2 + 1 = rchild.id;

To understand why this was designed as it is, we really need to know what the data is.

WorknHardrAuthor Commented:
Sorry for the delay. Here's the table create and data...

Note: Only 4 rows in the table!

[Create Table]
CREATE TABLE [dbo].[Types]
      [id] [int] IDENTITY(1,1) NOT NULL,
      [content_id] [int] NOT NULL,
      [details] [varchar](max) NULL

REFERENCES [dbo].[_Types] ([id])


id      content_id       details
11      14                       These details are for the benefit of....
12      28                       nothing
23      4                       Use this form for prior...
24      31                       NULL
WorknHardrAuthor Commented:

Featured Post

[Webinar] Kill tickets & tabs using PowerShell

Are you tired of cycling through the same browser tabs everyday to close the same repetitive tickets? In this webinar JumpCloud will show how you can leverage RESTful APIs to build your own PowerShell modules to kill tickets & tabs using the PowerShell command Invoke-RestMethod.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now