March 9, 2010 at 9:20 pm
Comments posted to this topic are about the item Primary Keys
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
March 9, 2010 at 9:35 pm
Tricky question!
March 9, 2010 at 9:46 pm
Nice question. Keep 'em coming.
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
March 9, 2010 at 9:51 pm
A thought provoking question, but I'm not too keen on the answer. Unless Paul would like to pay for my airfares???
S.
March 9, 2010 at 11:26 pm
A Primary Key is always enforced by a clustered index at creation?
Correct answer (SQL Server Central) : False
I would just like to add a small point, whenever you create a Primary Key, by default its ALWAYS going to be Clustered. Unless you create a Non Clustered Index Primary Key.
So, when you are saying that IF a Clustered Index already exists, then your what you are mentioning is valid. Else the Primary key, which is usually created at when you are creating the table, would be Clustered index unless specified.
Kindly reply if there is something else to add or I haev misquoted anywhere.
Warm regards,
Sameer Chachad.
March 10, 2010 at 12:30 am
hi sameer,
nice question.... you r question it self has the answwer..
The actual question asked is
A Primary Key is always enforced by a clustered index at creation?
which is not always done, it is enforced by a clustered index only when there is no clustered index existing on that table. If there is an clustered index existing in that table, the primary key u r going to create will be enforced by a non clustered index.
please notice the word "always" in the question...
🙂
[font="Times New Roman"]Anil Kubireddi[/font]
March 10, 2010 at 1:03 am
A Primary Key is created by defaut as a Clustered Index, unless a Clustered Index already exists on the table, which is really to say that the Clustered Index does not have to necessarily be the Primary Key. It is the semantics of how you are phrasing the question that is a little tricky and confusing for some. However, as you state Paul in your explanation, the more important piece to emphasize here is the reasoning of where you decide to put your Clustered Index on your table. Application functionality can drive this at times and a PK is not always the first choice . That said, primary keys do tend to make make good candiates for the CI simply because they and their auto-incrementing data (singleton PK columns are many times IDENTITY columns as well, although not required to be) automatically satisfy two main requirements of a Primary Key. NO NULLS and Unique data, where Unique Keys can allow one NULL and are created Non-Clustered by default and can have more than one UK on a table I believe. Both PK's and UK's can be made up of more than one column as well. . 🙂
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
March 10, 2010 at 1:24 am
sameerchachad 69959 (3/9/2010)
A Primary Key is always enforced by a clustered index at creation?Correct answer (SQL Server Central) : False
I would just like to add a small point, whenever you create a Primary Key, by default its ALWAYS going to be Clustered. Unless you create a Non Clustered Index Primary Key.
So, when you are saying that IF a Clustered Index already exists, then your what you are mentioning is valid. Else the Primary key, which is usually created at when you are creating the table, would be Clustered index unless specified.
Kindly reply if there is something else to add or I haev misquoted anywhere.
Warm regards,
Sameer Chachad.
The answer given by Paul is correct but incomplete. The explanation correctly describes what happens if you do not specify a clustering option for the PRIMARY KEY constraint, but it doesn't include the extra possibilities that arise from adding the keyword CLUSTERED or NONCLUSTERED to the constraint.
These are the scenarios that are possible when a PRIMARY KEY constraint is created:
1) No clustered index exists for the table, no clustering option specified for the constraint --> Clustered index is created. (This is probably the most common scenario)
2) No clustered index exists for the table, CLUSTERED option specified for the constraint --> Clustered index is created.
3) No clustered index exists for the table, NONCLUSTERED option specified for the constraint --> Non-clustered index is created.
4) A clustered index already exists for the table, no clustering option specified for the constraint --> Non-clustered index is created.
5) A clustered index already exists for the table, CLUSTERED option specified for the constraint --> No index created; error 1902 raised; constraint not created.
6) A clustered index exists for the table, NONCLUSTERED option specified for the constraint --> Non-clustered index is created.
Still, a great question. I really hope that Paul and Kimberly continue to submit questions, even if they don't have a seminar to promote.
(edit: small but important typo in option 6 - thanks, Shaiju C.K., for alerting me to it)
March 10, 2010 at 1:27 am
trickey question...already existing Clustered Index just went off from my mind and I answered TRUE...I was wondering why Paul would have asked such a simple question and w/o giving it a 2nd thought I happened to answered it wrong...:-D
March 10, 2010 at 2:21 am
Paul Randal,
When you ask\ write any question mention your assumption.
March 10, 2010 at 3:26 am
Good question :).
Forces thinking about why you might not want to, and that that executing DDL statements without understanding the underlying context can lead to unexpected results.
I don't think there was any need for the question to lay out any further assumptions, as it is a DBAs/SQL Developers jobs to question their own assumptions about the environment they are developing against/managing (?).
March 10, 2010 at 5:04 am
Folks - this is another questions written by Kimberly - not sure why it's posted under my account instead of hers.
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
March 10, 2010 at 6:06 am
Hey there everyone - I know people are feeling like was trying to trick them in the question but I guess the "always" part is what I thought would have been the dead give away. It's really rather simple actually - a Primary Key is NOT always enforced by a clustered index. I think if you read it this way it's simple. As stated by others, the obvious case is when you actually state NONCLUSTERED in the index definition but the "tricky" one is when a clustered index always exists. This is the one that I think a lot of people forget about... But, there are a bunch of combinations that are actually possible and Hugo's answer is very complete. Be sure to review that.
The end result is that there are a lot of things that people think "always" happen in SQL Server and when we become complacent - we get caught (myself included - that's not meant negatively... we all have to be careful!!). I've seen many cases where people just expect that their PKs are always enforced by a clustered and most are...but, then they have problems and there's that one (and then I hear, oh, yeah, I forgot I.........).
Even more so I see a lot of confusion around these three things: the PK, the clustered index and an identity column. There are a lot of assumptions that those are the same thing - even some that think they are inseparable. It's really important to realize that they do not have the be the same thing. They are 3 completely different things (yes, the often come together) but they really are controllable at any level. And, sometimes they should be. It's really more about making the *right* choices - for YOUR workloads. Understanding the internals to make informed decisions about your table design so that you get the best performance in Microsoft SQL Server. What I do in MSSQL is not going to be the same thing I'd do in other environments. This is what's tricky. This is why we're all here. 😉
It's *very* hard in SQL Server to ever say "always" or "never"... except for turning on autoshrink. *NEVER* do that!!! 😉
Cheers,
Kimberly
March 10, 2010 at 6:20 am
nargade 3404 (3/10/2010)
Paul Randal,When you ask\ write any question mention your assumption.
No assumptions needed. If you look at the syntax for creating a PRIMARY KEY, the default may be to create a clustered index, but that is not always how it is created. You can create it as a nonclustered index as well.
March 10, 2010 at 7:17 am
sameerchachad 69959 (3/9/2010)
I would just like to add a small point, whenever you create a Primary Key, by default its ALWAYS going to be Clustered. Unless you create a Non Clustered Index Primary Key.
I think you're emphasizing this a little wrong. The default setting is clustered, but you change that at creation time. So it's not that it always creates the index clustered, but that if you don't change the setting, that is what is done.
Viewing 15 posts - 1 through 15 (of 39 total)
You must be logged in to reply to this topic. Login to reply