RE:
-
you are saying :"My recommendation to junior developers is pretty simple. Every table gets both a primary key and a clustered index. It may not be a "best" practice, but a damn good starting point is to just add a identity column called rowid and make it the primary key and the clustered key. As your skills increase you can start to look at more advanced alternatives. "
It's a good thing I think also having a primary key
. But a clustered index on a table which have 10 million lines is not a good one. Especially in production environnement. if this table have a lot of insert and delete statements, the cost will be very very high (as SQL have to organize physically the lines). 
That's my opinion. Whatever, Your article is interesting in that way that (I hope) It'll help newbies to take care about those important things. An other subject that would be interesting: Statistics.
Best regards,
P. RUELLO
DBA
-
Disagree. INSERTS won't hurt a clustered ID index, as the records just go in at the end and no reorg required.
The absence of evidence is not evidence of absence.
Martin ReesYou can lead a horse to water, but a pencil must be lead.
Stan Laurel -
It's ok for appending but if your record goes at the middle of the table (when PK = Clustered).... SQL have to physically move all the lines above.
-
I know - but your original post quotes 'an identity column called row id' - you cannot insert 'to the middle of the table' with such a design.
The absence of evidence is not evidence of absence.
Martin ReesYou can lead a horse to water, but a pencil must be lead.
Stan Laurel
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply