What are cons and pros for using IDENTITY property as PK in SQL SERVER 2000?

[Andy]

Hi All!

We are doing new development for SQL Server 2000 and also moving from
SQL 7.0 to SQL Server 2000.

What are cons and pros for using IDENTITY property as PK in SQL SERVER
2000?
Please, share your experience in using IDENTITY as PK .
Does SCOPE_IDENTITY makes life easier in SQL 2000?

Is there issues with DENTITY property when moving DB from one server
to another? (the same version of SQL Server)

Thank you in advance,
Andy

[Aaron Bertrand [MVP]]

> What are cons and pros for using IDENTITY property as PK in SQL SERVER

2000?
Pros:
- small (4 bytes)
- automatic
- relatively predictable (unlike GUID)
- more usable (try WHERE guidColumn = {AECB...} when debugging a problem)

Cons:
- meaningless identifier (this can also be a good thing)
- can have gaps (after delete or rollback)
- can't be used in some types of replication
- hotspot for insert if it is also clustered index
- not portable

We use it here because our natual keys are much larger than 4 bytes, and
this would be inefficient (especially in indexed foreign key constraints).
Does SCOPE_IDENTITY makes life easier in SQL 2000?
Yes, it is more reliable than @@IDENTITY... but I don't know how it would
make life easier.
Is there issues with DENTITY property when moving DB from one server
to another? (the same version of SQL Server)

Depends on how you define "move," and whether this is one-time or
continuous.

--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/

[Daniel Morgan]

Aaron Bertrand [MVP] wrote:

What are cons and pros for using IDENTITY property as PK in SQL SERVER
2000?

Pros:
- small (4 bytes)
- automatic
- relatively predictable (unlike GUID)
- more usable (try WHERE guidColumn = {AECB...} when debugging a problem)

Cons:
- meaningless identifier (this can also be a good thing)
- can have gaps (after delete or rollback)
- can't be used in some types of replication
- hotspot for insert if it is also clustered index
- not portable

We use it here because our natual keys are much larger than 4 bytes, and
this would be inefficient (especially in indexed foreign key constraints).

What does 4 bytes have to do with it? If you had said 60 or 100 I'd
understand but why 4?

And please consider Joe Celko's voluminous comments on the subject of
artificial, or surrogate keys, when responding.

Thanks.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Aaron Bertrand [MVP]]

> What does 4 bytes have to do with it? If you had said 60 or 100 I'd

understand but why 4?
Uh, because INT (the most common datatype for IDENTITY) is 4 bytes?
And please consider Joe Celko's voluminous comments on the subject of
artificial, or surrogate keys, when responding.

Joe's a big boy, and he can speak for himself. So can I. We don't all have
to agree on everything. This is why it's called an opinion.

--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/

[Bruce Lewis]

ne********@hotm ail.com (Andy) writes:

What are cons and pros for using IDENTITY property as PK in SQL SERVER
2000? Please, share your experience in using IDENTITY as PK .

My experience says the theorists are right about the dangers of an
artificial primary key. Many real-world database problems stem from
duplicates that would never have been there with a natural primary key.
Natural primary keys also result in reports with fewer joins.

As for the pros of IDENTITY, if you are going to use an artificial
primary key, that's the way to do it. Triggers don't work as well. A
pro for artificial keys in general is that Microsoft products make
compound primary keys inconvenient. Transact-SQL doesn't have tuple
comparisons, e.g. (a, b, c) = (x, y, z), making joins inconvenient.
ASP.NET components that do DataBind() don't handle compound keys at all.
AFAICT, you can only set a KeyColumn parameter to a single column.

I'd personally recommend going with natural primary keys, even if
they're compound.

[Louis Davidson]

> My experience says the theorists are right about the dangers of an

artificial primary key. Many real-world database problems stem from
duplicates that would never have been there with a natural primary key.
This is only partially true, since what is actually missing is analysis.
Tables can have many keys, and should if there are several reasonable
natural keys, or in this case artificial keys.
Natural primary keys also result in reports with fewer joins.
Only when you make the keys very descriptive. This kind of thing has always
made for an ugly balance of performance (smaller keys, resulting in values
that need 20 characters being condensed into 5) and usability. Joins on
very small values are very fast.
As for the pros of IDENTITY, if you are going to use an artificial
primary key, that's the way to do it. Triggers don't work as well. A
What do you mean by triggers don't work as well? There are ways to create
artificial keys using triggers.
pro for artificial keys in general is that Microsoft products make
compound primary keys inconvenient. Transact-SQL doesn't have tuple
comparisons, e.g. (a, b, c) = (x, y, z), making joins inconvenient.
What SQL syntax has this kind of comparison? I would have figured (a,b,c)
to be a set, not three different columns.
I'd personally recommend going with natural primary keys, even if
they're compound.

There is nothing wrong with that statement, whatsoever. Natural keys have
value, I just like the consistency of the same pattern being used for all
tables.

--
----------------------------------------------------------------------------
-----------
Louis Davidson (dr***@hotmail. com)
Compass Technology Management

Pro SQL Server 2000 Database Design
http://www.apress.com/book/bookDisplay.html?bID=266

Note: Please reply to the newsgroups only unless you are
interested in consulting services. All other replies will be ignored :)

[Bob Badour]

"Bruce Lewis" <br*****@yahoo. com> wrote in message
news:nm******** *****@scrubbing-bubbles.mit.edu ...

ne********@hotm ail.com (Andy) writes:

What are cons and pros for using IDENTITY property as PK in SQL SERVER
2000? Please, share your experience in using IDENTITY as PK .
My experience says the theorists are right ...

.... I'd personally recommend going with natural primary keys, even if
they're compound.

The theorists disagree with you with respect to compound primary keys --
especially in SQL. Candidate keys obviously have as many attributes as they
have, but forming references with compound keys causes severe problems when
information may be missing.

[David Portas]

> > comparisons, e.g. (a, b, c) = (x, y, z), making joins inconvenient.

What SQL syntax has this kind of comparison? I would have figured (a,b,c)
to be a set, not three different columns.

Row-value comparisons such as this are standard in SQL92 but unfortunately
not supported by SQLServer. Oracle, I believe, does support this feature.

--
David Portas
------------
Please reply only to the newsgroup
--

[Daniel Morgan]

Bob Badour wrote:

<snipped>

The theorists disagree with you with respect to compound primary keys --
especially in SQL. Candidate keys obviously have as many attributes as they
have, but forming references with compound keys causes severe problems when
information may be missing.

I disagree. Theorists do not disagree at all with respect to compound
primary keys. Primary keys, by definition, don't have missing information.

If you are missing information you have something but that something is
not, by definition, a primary key.
--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Bob Badour]

"Daniel Morgan" <da******@x.was hington.edu> wrote in message
news:1070326393 .444066@yasure. ..

Bob Badour wrote:

<snipped>

The theorists disagree with you with respect to compound primary keys --
especially in SQL. Candidate keys obviously have as many attributes as they have, but forming references with compound keys causes severe problems when information may be missing.

I disagree. Theorists do not disagree at all with respect to compound
primary keys. Primary keys, by definition, don't have missing information.

If you are missing information you have something but that something is
not, by definition, a primary key.

Since when does that have any bearing on missing data in the referencing
table?