| Author |
 Topic  |
|
Bustaz Kool
Flowing Fount of Yak Knowledge
USA
1440 Posts |
 Posted - 12/14/2004 : 18:10:01
|
My sincere regrets to one and all.
It just seemed so out of character for you, RockMoose...
HTH
=================================================================
Happy Holidays! |
 |
|
|
nr
SQLTeam MVY
United Kingdom
12543 Posts |
Posted - 12/14/2004 : 20:33:55
|
>> " A candidate key is similar to a primary key... When more than one primary key exists, the alternatives are called candidate keys. Of the two or more candidate keys, a primary key is selected, with the remaining keys becoming secondary keys."
Think that probably shows an understanding of concepts but a woeful lack of precise communication.
>> Let me rephrase that.. the current RM does not have a concept of a Primary Key. All keys are considered equally important. "Primary" is an old term that SQL has run with...
Maybe so but if a PK is defined then I think it should have particular attributes that distinguish it from other candiaidate keys - one being immutability.
If a table doesn't have a Pk then I think that's not a problem but it is saying that that table will never be involved in anything that requires a PK.
That's from an implementational point of view so I can get away with anything I want and ignore theory.
KMust admit I never used to define PKs as I always demanded control of all access and could do everything in SPs - so would never implement triggers, views, replication, .... but I'm a lot more mellow (or tired) now.
==========================================
Cursors are useful if you don't know sql.
DTS can be used in a similar way.
Beer is not cold and it isn't fizzy. |
|
|
|
rockmoose
SQL Natt Alfen
Sweden
3279 Posts |
Posted - 12/15/2004 : 17:57:45
|
No hard feelings Bustaz.
>> Maybe so but if a PK is defined then I think it should have particular attributes that distinguish it from other candiaidate keys - one being immutability.
In SQL server this can only? be achieved by "domain tables" and check constraints(sort of),
or identities(sort of), or with triggers(can be disabled), or with DENY(except for sysadm).
I do agree with nigel that an "immutable" attribute for a (p)key would be desirable for (p)keys.
It could simplify RI in some cases.
rockmoose |
|
|
|
Topic |
|
Primary Key v. Unique Index
