Is a Primary Key an index?

Question

Is a Primary Key an index?

Viewing 10 posts - 46 through 54 (of 54 total)

You must be logged in to reply to this topic. Login to reply

sektor81 Say Hey Kid Points: 679 More actions · Answer 1

Well, according to SQL Server BOL:

PRIMARY KEY
Is a constraint that enforces entity integrity for a specified column or columns through a unique index. Only one PRIMARY KEY constraint can be created per table.

Sergiy SSC Guru Points: 110208 More actions · Answer 2

Phil Factor (7/17/2014)
@Sergei
Please correct me if I'm wrong but I'd always believed a primary key was enforced by a constraint which was implemented by means of both a UNIQUE index and NOT NULL constraints on all the participating columns.

Not quite.

But I'll write about it later in a separate post.

The reason for my pedantry is nothing to do with metaphysics but all to do with foreign keys, and candidate keys. Hmmm. I've maybe got a few more QOTDs to do, even if I'm really just asking myself.

If we're talking about foreign keys and candidate keys there is no diffeence between PK and UNIQUE.

I often use UNIQUE instead of PRIMARY KEY when I need to allow NULL into a PK column.

_____________
Code for TallyGenerator

Sergiy SSC Guru Points: 110208 More actions · Answer 3

Steve Lund (7/17/2014)
Interesting also, is that when you create a PK on a table, in SSMS that it lists that PK under Indexes and not under Constraints.

Look under "Keys".

It's another silly thing in SSMS, indicating that it was designed by people who did not have a clue.

_____________
Code for TallyGenerator

Sergiy SSC Guru Points: 110208 More actions · Answer 4

Koen Verbeeck (7/17/2014)
Sergiy (7/16/2014)
Koen Verbeeck (7/16/2014)
So it is 100% possible to decouple the primary key from the index
Can you illustrate how?
Easy peasy. I draw a table diagram in Visio and declare the combination of a few columns to be the primary key.
(in other words, I am creating the logical design)
Where do you see an index?

I do not see a primery key here either.

I do not even see a database.

It's just a set of drawings, labels, indicated intentions.

As soon you try to turn it into an actual database and actually create that PK the corresponding index will be there.

_____________
Code for TallyGenerator

Phil Parkin SSC Guru Points: 246987 More actions · Answer 5

Sergiy (7/18/2014)
Koen Verbeeck (7/17/2014)
Sergiy (7/16/2014)
Koen Verbeeck (7/16/2014)
So it is 100% possible to decouple the primary key from the index
Can you illustrate how?
Easy peasy. I draw a table diagram in Visio and declare the combination of a few columns to be the primary key.
(in other words, I am creating the logical design)
Where do you see an index?
I do not see a primery key here either.
I do not even see a database.
It's just a set of drawings, labels, indicated intentions.
As soon you try to turn it into an actual database and actually create that PK the corresponding index will be there.

You appear to be suggesting that a primary key does not and can not exist unless it is physically implemented in a database - is that the case?

Meaning, presumably, that you object to a basic database design document using the term 'primary key'.

Perhaps instead you refer to a relation's "default unique-row identifier(s)". Does the job, I suppose.

The absence of evidence is not evidence of absence.
Martin Rees

You can lead a horse to water, but a pencil must be lead.
Stan Laurel

Koen Verbeeck SSC Guru Points: 259115 More actions · Answer 6

Sergiy (7/18/2014)
As soon you try to turn it into an actual database and actually create that PK the corresponding index will be there.

Again, that is just the physical manifistation of the primary key.

It may change from database implementation to another. What if Microsoft had decided to implement it in a whole different way?

Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP

TomThomson SSC Guru Points: 104773 More actions · Answer 7

Phil Factor (7/17/2014)
@Sergei
Please correct me if I'm wrong but I'd always believed a primary key was enforced by a constraint which was implemented by means of both a UNIQUE index and NOT NULL constraints on all the participating columns.

@Phil, you are wrong (but your QotD is correct, of course, a primary key is not an index).

A primary key is not a constraint. There are two acceptable definitions in relational theory: (1) it is the candidate key (set of columns) chosen to be the principal means of reaching/identifying individual rows in a relation, or (2) it is the value of a primary key as defined by (1) in a particular row.

Neither of those things is a primary key constraint. A primary key constraint is a constraint that ensures that the primary key is fully defined (ie includes no NULL values) in every row, and that the projection of the relation onto the columns involved in the primary key contains no duplicates, ie the set of columns involved in the primary key is a superkey so it can be used to reach or identify an individual row - while theory talks about candidate keys and database design attempts to discover them by understanding what real world rules apply to the data, an RDBMS can't implement a constraint which enforces the candidate key property other than for single column keys - in effect the constraint that the primary key be a candidate key rather than just a superkey is a theoretical (and often ignored or broken) constraint on the schema design, not a constraint on the data.

The primary key constraint is implemented as a set of constraints: a domain constraint for each column involved in the key that specifies that the domain excludes NULL and a uniqueness constraint that ensures there are no duplicates; the uniqueness constraint is in turn implemented (in almost every RDBMS) using an index.

Tom

sqlvogel SSCrazy Eights Points: 9526 More actions · Answer 8

Here's a small example:

CREATE TABLE t

(x INT NOT NULL UNIQUE,

y INT NOT NULL,

z INT NOT NULL UNIQUE,

CONSTRAINT pkc PRIMARY KEY (x,y));

"pkc" is not the primary key of this table - it's just a constraint. (x,y) is not the primary key either. As Tom already mentioned, in SQL the constraint called "PRIMARY KEY" is a superkey constraint whereas the actual primary key is by definition supposed to be a candidate key and not just any superkey. In this unusual example (x) is defined to be a unique single column and therefore (x,y) is not a candidate key because it isn't irreducibly unique - it isn't the smallest subset of unique attributes of a superkey. Either (x) or (z) could be the primary key of this table, but (x,y) certainly can't be.

So in principle a primary key doesn't have to be the set of columns defined by a PRIMARY KEY constraint. A PRIMARY KEY constraint can be thought of as a technical feature which common sense suggests ought to be used to identify the actual primary key columns, but it doesn't have to be used that way. Once you realise that fact, I think it follows that even in a SQL Server database a primary key doesn't have to require a corresponding index. It is possible (though usually not desirable) to enforce uniqueness in other ways without a specific index: by using a combination of CHECK constraints for example. The primary key of a table might just as well be some column(s) whose uniqueness is enforced without using an index.

Is it sensible that SQL Server creates indexes whenever we use the PRIMARY KEY syntax? Usually it makes sense to do so, but it is also a product limitation. It would be nice to have the option to create uniqueness constraint (PRIMARY KEY or UNIQUE) without SQL Server always creating a new index. Other DBMSs allow that. SQL Server does not.

Miles Neale SSChampion Points: 13147 More actions · Answer 9

Read it, thought about it, missed it, learned from it, and moved on from it.

Thanks, good question.

Not all gray hairs are Dinosaurs!

sqlnaive SSCoach Points: 17437 More actions · Answer 10

TomThomson (7/15/2014)
Irritating because over-pedantic. Good question nevertheless.

+1