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 «««23456

Is a Primary Key an index? Expand / Collapse
Author
Message
Posted Friday, July 18, 2014 12:21 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 9:43 AM
Points: 5,078, Visits: 11,861
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.



Help us to help you. For better, quicker and more-focused answers to your questions, consider following the advice in this link.

When you ask a question (and please do ask a question: "My T-SQL does not work" just doesn't cut it), please provide enough information for us to understand its context.
Post #1593916
Posted Friday, July 18, 2014 1:03 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 2:22 PM
Points: 12,956, Visits: 10,726
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?




How to post forum questions.
Need an answer? No, you need a question.
What’s the deal with Excel & SSIS?

Member of LinkedIn. My blog at LessThanDot.

MCSA SQL Server 2012 - MCSE Business Intelligence
Post #1593925
Posted Friday, July 18, 2014 3:58 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 7:20 AM
Points: 7,696, Visits: 9,424
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
Post #1593964
Posted Saturday, July 19, 2014 4:30 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Yesterday @ 11:09 AM
Points: 448, Visits: 3,356
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.



David
Post #1594300
Posted Monday, July 21, 2014 2:20 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 12:15 PM
Points: 2,345, Visits: 1,403
Read it, thought about it, missed it, learned from it, and moved on from it.

Thanks, good question.


Not all gray hairs are Dinosaurs!
Post #1594825
Posted Monday, August 4, 2014 5:40 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Thursday, September 4, 2014 7:40 AM
Points: 3,545, Visits: 2,652
TomThomson (7/15/2014)
Irritating because over-pedantic. Good question nevertheless.


+1
Post #1599206
« Prev Topic | Next Topic »

Add to briefcase «««23456

Permissions Expand / Collapse