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

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).

Yes, it is more reliable than @@IDENTITY... but I don't know how it would
make life easier.

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

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

Aaron Bertrand [MVP] wrote:
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
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

Uh, because INT (the most common datatype for IDENTITY) is 4 bytes?

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/

net__space (AT) hotmail (DOT) com (Andy) writes:

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.

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.

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.
What do you mean by triggers don't work as well? There are ways to create
artificial keys using triggers.

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

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 (drsql (AT) hotmail (DOT) 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

"Bruce Lewis" <brlspam (AT) yahoo (DOT) com> wrote

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.

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

Bob Badour wrote:

<snipped>

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
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

"Daniel Morgan" <damorgan@x.washington.edu> wrote

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