July 17, 2014 at 11:53 pm
Phil Factor (7/17/2014)
@SergeiPlease 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
July 17, 2014 at 11:55 pm
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
July 18, 2014 at 12:03 am
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 indexCan 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
July 18, 2014 at 12:21 am
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 indexCan 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.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
July 18, 2014 at 1:03 am
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
July 18, 2014 at 3:58 am
Phil Factor (7/17/2014)
@SergeiPlease 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
July 19, 2014 at 4:30 am
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.
July 21, 2014 at 2:20 pm
Read it, thought about it, missed it, learned from it, and moved on from it.
Thanks, good question.
Not all gray hairs are Dinosaurs!
August 4, 2014 at 5:40 am
TomThomson (7/15/2014)
Irritating because over-pedantic. Good question nevertheless.
+1
Viewing 10 posts - 46 through 54 (of 54 total)
You must be logged in to reply to this topic. Login to reply