Re: Update Identity Column
- From: "Robert Morley" <rmorley@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 27 Aug 2007 14:44:20 -0400
You're right, the table is unsorted in the SQL 2K EM (either your example or
my actual table), though I'm sure it used to come up sorted previously.
It's not like I open that particular table directly all that often, so
perhaps it was conicidence or some such.
But regardless of that, as I said, what else was I to do here? I wanted to
take every possible precaution to ensure that in most possible sorts and/or
views of the data, somebody would notice the line that said to contact me
before adding to the data, so I wanted to include even the identity in that.
It's no guarantee, I'll grant, but it's better than trusting that anyone who
ever accesses my data will ignore that column as much as I normally would.
As you say, nobody SHOULD assign any importance to an Identity column...but
that doesn't mean that nobody WILL.
And as to that, I have never assigned any more importance to Identity
columns than anybody else ever has. I've been a DBA for about 15 years now
(not all of it SQL Server, mind you), so believe me, I know my way around.
It sucks that I would have a desire to ever take this kind of measure, but
it should tell you how often I've had to do it before that I had to ask how
to do it (and even then, the first response was not an ideal solution).
But now you've got me thinking...perhaps my approach to this was wrong.
Since I'm the only one who will ever add data to the table, perhaps I should
add a trigger to the table that effectively forbids anybody not named Robert
Morley from doing so (not even the server admins). An admin could still
remove the trigger in the event that I get hit by a bus (even though I work
from home), but only someone bent on adding data to the table would actually
be able to do so, and would likely contact me unless there was a REALLY good
reason not to. Hmmm...something to look into.
Rob
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@xxxxxxx> wrote in message
news:OUWKWON6HHA.484@xxxxxxxxxxxxxxxxxxxxxxx
"Robert Morley" <rmorley@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:er$3DPE6HHA.5424@xxxxxxxxxxxxxxxxxxxxxxx
While it's true that the sort order is undefined, having a clustered
index on the primary key (as most of my tables do), the data will
normally be sorted and stored physically in that order, and therefore SQL
Server will almost invariably decide that that's the best order to
retrieve it in.
Not true. Not even "almost invariably" true:
CREATE TABLE tbl
(x INT NOT NULL PRIMARY KEY CLUSTERED,
z INT NOT NULL UNIQUE);
INSERT INTO tbl (x,z) VALUES (1,30);
INSERT INTO tbl (x,z) VALUES (2,20);
INSERT INTO tbl (x,z) VALUES (3,10);
SELECT x,z FROM tbl;
Result (YMMV):
x z
----------- -----------
3 10
2 20
1 30
(3 row(s) affected)
I agree with Sylvain. Ascribing any significance to the ordering of
IDENTITY column values is just folly.
--
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--
.
- Follow-Ups:
- Re: Update Identity Column
- From: Sylvain Lafontaine
- Re: Update Identity Column
- References:
- Update Identity Column
- From: Robert Morley
- Re: Update Identity Column
- From: Sylvain Lafontaine
- Re: Update Identity Column
- From: Robert Morley
- Re: Update Identity Column
- From: Sylvain Lafontaine
- Re: Update Identity Column
- From: Robert Morley
- Re: Update Identity Column
- From: David Portas
- Re: Update Identity Column
- From: Robert Morley
- Re: Update Identity Column
- From: David Portas
- Update Identity Column
- Prev by Date: Re: Update Identity Column
- Next by Date: Nouvel abonné
- Previous by thread: Re: Update Identity Column
- Next by thread: Re: Update Identity Column
- Index(es):
Relevant Pages
|