Identity Crisis: Attack of the Clone

Question

Post reply

Identity Crisis: Attack of the Clone

Viewing 15 posts - 16 through 30 (of 35 total)

You must be logged in to reply to this topic. Login to reply

SanDroid SSChampion Points: 10068 More actions · Answer 1

Good easy question, but I do not agree with the answers explination.

A unique constraint is what a table needs to garuntee an column does not repeat values.

Making a column part of a Primary Key value does create a constraint for Unique values.

That is the effect not the cause.

If both columns in the table are selected as Primary Key, then you could still insert duplicates into the Unique_Id column.

Make sure your Identity columns have there own Unique Index and/or value constraint and you don't have to worry about dupes.

SanDroid SSChampion Points: 10068 More actions · Answer 2

Richard Warr (5/11/2011)
A question that enables most people to get the correct answer after some careful thought is by no means "too simple". Especially as over 1/3 of respondants have got it wrong.
For me this was close to a "Goldilocks" question. For some it's too hard, for others too soft, but for many, it's just right.

LOL... Richard I could not agree more. :hehe:

Chris Umbaugh Ten Centuries Points: 1284 More actions · Answer 3

good question and explanation.

Thanks.

Chris Umbaugh
Data Warehouse / Business Intelligence Consultant
twitter @ToledoSQL

mtassin SSC-Insane Points: 23099 More actions · Answer 4

Richard Warr (5/11/2011)
A question that enables most people to get the correct answer after some careful thought is by no means "too simple". Especially as over 1/3 of respondants have got it wrong.
For me this was close to a "Goldilocks" question. For some it's too hard, for others too soft, but for many, it's just right.

I got it wrong... only because of two things.

1. I've spent the past several weeks going through hundreds of tables with structures like

CREATE TABLE staff(

STAFFID INT IDENTITY(1,1) NOT NULL,

STAFFNAME VARCHAR(100))

CREATE UNIQUE CLUSTERED INDEX UCI_PK ON staff(STAFFID)

At that point, just call the bloody thing a primary key.

So I see INT IDENTITY(1,1) and these days I assume PRIMARY KEY is stuck on the end of it.

Then I misread the answer that said it was a violation of the IDENTITY constraint. Which I know isn't a constraint... I was just rushed because I have a meeting in 10 min. 🙂

Oops.

--Mark Tassin
MCITP - SQL Server DBA
Proud member of the Anti-RBAR alliance.
For help with Performance click this link[/url]
For tips on how to post your problems[/url]

steven.chester Grasshopper Points: 14 More actions · Answer 5

What's funny is that I couldn't pick my first answer: a syntax error. There's a superfluous comma in the DDL for the table.

srkrell Ten Centuries Points: 1348 More actions · Answer 6

Excellent Question and thorough explanation.

Thanks!

WayneS SSC Guru Points: 95409 More actions · Answer 7

Tom.Thomson (5/11/2011)
Nice question.
One niggle: asking people to assume that a schema is valid when a table doesn't have a primary key may encourage a very bad habit if some of your audience don't know any better. Maybe "pretend" would have been a better choice of word than "assume".

Tom, I think it was referring to the schema "Playground", which the table was created in.

Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes

If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!

Links:
For better assistance in answering your questions
Performance Problems
Common date/time routines
Understanding and Using APPLY Part 1 & Part 2

WayneS SSC Guru Points: 95409 More actions · Answer 8

Good question - thanks!

Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes

If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!

Links:
For better assistance in answering your questions
Performance Problems
Common date/time routines
Understanding and Using APPLY Part 1 & Part 2

SanDroid SSChampion Points: 10068 More actions · Answer 9

steven.chester (5/11/2011)
What's funny is that I couldn't pick my first answer: a syntax error. There's a superfluous comma in the DDL for the table.

That comma does not generate any error when the code is executed as listed in the QOTD. 😛

Of course you would need to execute this command before you execute the QOTD SQL to test that. Don't forget to replace parameters.

CREATE SCHEMA PLAYGROUND AUTHORIZATION <Your User Name, sysname, DBuser>

GO

toddasd SSCertifiable Points: 6298 More actions · Answer 10

mtassin (5/11/2011)...
At that point, just call the bloody thing a primary key.
So I see INT IDENTITY(1,1) and these days I assume PRIMARY KEY is stuck on the end of it.
Then I misread the answer that said it was a violation of the IDENTITY constraint. Which I know isn't a constraint... I was just rushed because I have a meeting in 10 min. 🙂
Oops.

Same here Mark. After seeing Identity and primary key together for years, my mind automatically puts them together. I need to start paying atte...ooh, look, ice cream!

Good question.

______________________________________________________________________________
How I want a drink, alcoholic of course, after the heavy lectures involving quantum mechanics.

FargoUT SSC Eights! Points: 853 More actions · Answer 11

WayneS (5/11/2011)
Tom.Thomson (5/11/2011)
Nice question.
One niggle: asking people to assume that a schema is valid when a table doesn't have a primary key may encourage a very bad habit if some of your audience don't know any better. Maybe "pretend" would have been a better choice of word than "assume".
Tom, I think it was referring to the schema "Playground", which the table was created in.

I think he was implying that the table's schema (not the Playground schema -- confused yet?) is not appropriate since there is no primary key or unique identifier. Someone may read the question and assume the table's structure is good practice when it is not.

SQLRNNR SSC Guru Points: 281334 More actions · Answer 12

nice and straight forward - thanks

Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events

Peter Trast SSCarpal Tunnel Points: 4392 More actions · Answer 13

Almost got it wrong until I remembered that IDENTITY does not have to be UNIQUE 🙂 I just WANT it to be... made me read carefully. That's why I think this is a great question.

Peter Trast
Microsoft Certified ...(insert many literal strings here)
Microsoft Design Architect with Alexander Open Systems

TomThomson SSC Guru Points: 104773 More actions · Answer 14

WayneS (5/11/2011)
Tom.Thomson (5/11/2011)
Nice question.
One niggle: asking people to assume that a schema is valid when a table doesn't have a primary key may encourage a very bad habit if some of your audience don't know any better. Maybe "pretend" would have been a better choice of word than "assume".
Tom, I think it was referring to the schema "Playground", which the table was created in.

Ah, yes, probably. My mistake. I find it hard at times to remember that MS misuses this particular term so horribly, and my reaction :alien: was as it was because I interpreted "schema" as "schema" rather than as what MS calls "schema". Must remember loony MS terminology in future :(.

Tom

Surii Default port Points: 1497 More actions · Answer 15

Surii

Default port

Points: 1497

May 11, 2011 at 9:18 pm

#1323461

Excellent question.