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

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

> What are cons and pros for using IDENTITY property as PK in SQL SERVER[color=blue]
> 2000?[/color]

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).
[color=blue]
> Does SCOPE_IDENTITY makes life easier in SQL 2000?[/color]

Yes, it is more reliable than @@IDENTITY... but I don't know how it would
make life easier.
[color=blue]
> Is there issues with DENTITY property when moving DB from one server
> to another? (the same version of SQL Server)[/color]

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]

Re: What are cons and pros for using IDENTITY property as PK in SQLSERVER 2000?

Aaron Bertrand [MVP] wrote:[color=blue][color=green]
>>What are cons and pros for using IDENTITY property as PK in SQL SERVER
>>2000?[/color]
>
>
> 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).[/color]

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/ext/certificates/oad/oad_crs.asp

http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp

damorgan@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Aaron Bertrand [MVP]]

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

> What does 4 bytes have to do with it? If you had said 60 or 100 I'd[color=blue]
> understand but why 4?[/color]

Uh, because INT (the most common datatype for IDENTITY) is 4 bytes?
[color=blue]
> And please consider Joe Celko's voluminous comments on the subject of
> artificial, or surrogate keys, when responding.[/color]

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]

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

net__space@hotm ail.com (Andy) writes:
[color=blue]
> What are cons and pros for using IDENTITY property as PK in SQL SERVER
> 2000? Please, share your experience in using IDENTITY as PK .[/color]

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]

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

> My experience says the theorists are right about the dangers of an[color=blue]
> artificial primary key. Many real-world database problems stem from
> duplicates that would never have been there with a natural primary key.[/color]

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.
[color=blue]
> Natural primary keys also result in reports with fewer joins.[/color]

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.[color=blue]
>
> 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[/color]

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

What SQL syntax has this kind of comparison? I would have figured (a,b,c)
to be a set, not three different columns.
[color=blue]
> I'd personally recommend going with natural primary keys, even if
> they're compound.[/color]

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

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


"Bruce Lewis" <brlspam@yahoo. com> wrote in message
news:nm97k1gboh 8.fsf@scrubbing-bubbles.mit.edu ...[color=blue]
> net__space@hotm ail.com (Andy) writes:
>[color=green]
> > What are cons and pros for using IDENTITY property as PK in SQL SERVER
> > 2000? Please, share your experience in using IDENTITY as PK .[/color]
>
> My experience says the theorists are right ...[/color]
....[color=blue]
> I'd personally recommend going with natural primary keys, even if
> they're compound.[/color]

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]

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

> > comparisons, e.g. (a, b, c) = (x, y, z), making joins inconvenient.[color=blue]
>
> What SQL syntax has this kind of comparison? I would have figured (a,b,c)
> to be a set, not three different columns.[/color]

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]

Re: What are cons and pros for using IDENTITY property as PK in SQLSERVER 2000?

Bob Badour wrote:

<snipped>
[color=blue]
> 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.[/color]

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/ext/certificates/oad/oad_crs.asp

http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp

damorgan@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Bob Badour]

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

"Daniel Morgan" <damorgan@x.was hington.edu> wrote in message
news:1070326393 .444066@yasure. ..[color=blue]
> Bob Badour wrote:
>
> <snipped>
>[color=green]
> > The theorists disagree with you with respect to compound primary keys --
> > especially in SQL. Candidate keys obviously have as many attributes as[/color][/color]
they[color=blue][color=green]
> > have, but forming references with compound keys causes severe problems[/color][/color]
when[color=blue][color=green]
> > information may be missing.[/color]
>
> 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.[/color]

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

[Louis Davidson]

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

While it is true that the chosen primary key cannot contain any optional
values, it is more the praticioner (sp?) that disagrees with this stance.
Compound keys are unwieldy and bad for performance, but the theorist in me
says "who cares?" It is all about what is right/best, not what is
fastest/easiest.

--
----------------------------------------------------------------------------
-----------
Louis Davidson (drsql@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" <bbadour@golden .net> wrote in message
news:pfqdnbyWFq c951aiRVn-hA@golden.net.. .[color=blue]
>
> "Bruce Lewis" <brlspam@yahoo. com> wrote in message
> news:nm97k1gboh 8.fsf@scrubbing-bubbles.mit.edu ...[color=green]
> > net__space@hotm ail.com (Andy) writes:
> >[color=darkred]
> > > What are cons and pros for using IDENTITY property as PK in SQL SERVER
> > > 2000? Please, share your experience in using IDENTITY as PK .[/color]
> >
> > My experience says the theorists are right ...[/color]
> ...[color=green]
> > I'd personally recommend going with natural primary keys, even if
> > they're compound.[/color]
>
> The theorists disagree with you with respect to compound primary keys --
> especially in SQL. Candidate keys obviously have as many attributes as[/color]
they[color=blue]
> have, but forming references with compound keys causes severe problems[/color]
when[color=blue]
> information may be missing.
>
>[/color]

[Bob Badour]

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


"Louis Davidson" <dr_dontspamme_ sql@hotmail.com > wrote in message
news:#rIbinJuDH A.3436@tk2msftn gp13.phx.gbl...[color=blue]
> While it is true that the chosen primary key cannot contain any optional
> values, it is more the praticioner (sp?) that disagrees with this stance.
> Compound keys are unwieldy and bad for performance, but the theorist in me
> says "who cares?" It is all about what is right/best, not what is
> fastest/easiest.[/color]

Performance is determined by the physical structure and not by the logical
interface. Legitimate theorists have written ad nauseum on the severe
logical problems caused by using compound keys for references when data may
be missing.

[color=blue]
> --------------------------------------------------------------------------[/color]
--[color=blue]
> -----------
> Louis Davidson (drsql@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" <bbadour@golden .net> wrote in message
> news:pfqdnbyWFq c951aiRVn-hA@golden.net.. .[color=green]
> >
> > "Bruce Lewis" <brlspam@yahoo. com> wrote in message
> > news:nm97k1gboh 8.fsf@scrubbing-bubbles.mit.edu ...[color=darkred]
> > > net__space@hotm ail.com (Andy) writes:
> > >
> > > > What are cons and pros for using IDENTITY property as PK in SQL[/color][/color][/color]
SERVER[color=blue][color=green][color=darkred]
> > > > 2000? Please, share your experience in using IDENTITY as PK .
> > >
> > > My experience says the theorists are right ...[/color]
> > ...[color=darkred]
> > > I'd personally recommend going with natural primary keys, even if
> > > they're compound.[/color]
> >
> > The theorists disagree with you with respect to compound primary keys --
> > especially in SQL. Candidate keys obviously have as many attributes as[/color]
> they[color=green]
> > have, but forming references with compound keys causes severe problems[/color]
> when[color=green]
> > information may be missing.
> >
> >[/color]
>
>[/color]

[Aaron Bertrand - MVP]

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

> "who cares?" It is all about what is right/best, not what is[color=blue]
> fastest/easiest.[/color]

Unfortunately, what is right/best is not always among the criteria when the
work is for someone else.

--
Aaron Bertrand
SQL Server MVP

http://www.aspfaq.com/

[BenignVanilla]

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


"Bruce Lewis" <brlspam@yahoo. com> wrote in message
news:nm97k1gboh 8.fsf@scrubbing-bubbles.mit.edu ...[color=blue]
> net__space@hotm ail.com (Andy) writes:
>[color=green]
> > What are cons and pros for using IDENTITY property as PK in SQL SERVER
> > 2000? Please, share your experience in using IDENTITY as PK .[/color]
>
> 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.[/color]

I am by no means a SQL expert, so forgive me if this seems ignorant...But
why can't the ID columm be a natural key? For example, I am working on a
project that has a vendors table. The list of vendors is used in
relationship to several other tables. We build this table with an identity
column, and a column with the vendor's name. Now when a vendor is added to
the table, they are assigned a unique ID that ties all other related data
back to this vendor, and in the case of a vendor changing their name, or a
typo, we can make updates without affecting data. Seems like a perfect use
for an identity field, and it is our primary key.


--
BV.
WebPorgmaster - www.IHeartMyPond.com
Work at Home, Save the Environment - www.amothersdream.com

[Aaron Bertrand - MVP]

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

> I am by no means a SQL expert, so forgive me if this seems ignorant...But[color=blue]
> why can't the ID columm be a natural key? For example, I am working on a
> project that has a vendors table. The list of vendors is used in
> relationship to several other tables. We build this table with an identity[/color]

An identity value that is generated by the system is not "natural".. . a
natural key means that the key is, by nature, identifying a single row...
not artificially because you generated some value for it. A natural key
could be an e-mail address, or a social security number, or a license plate
number, or a latitude and longitude -- something that is part of the data
that also happens to uniquely identify it.

Keep in mind that a primary key does not have to a natural key. I don't see
any problems with using an IDENTITY as a primary key, such as in your case.
But in your case it is not a natural key.

--
Aaron Bertrand
SQL Server MVP

http://www.aspfaq.com/