have one or more indexes on the fields that would have been part of a
natural primary key, which may need to be updated when the record is
changed.
Of course, all indexes involving fields that have been modified must be updated, but
if the primary key cannot be modified, that is one less index to update.
>> the database may lock the leaf, page or extent containing those
records. I've heard this called an index "hotspot" before.
The database will always have to lock the page it is adding a key in.
But adding a key at the end make sure that first you don't have to look in which page
the key must be added, second, you never have to split the page in two when inserting
a new key.
Now, you're right that this implies that the last page may become busy if hundreds of users
are adding new records in the same time, but the lock-update-unlock
process is very short.
>>I suspect that the difference in performance between an integer and a
GUID/UUID is relatively minor.
The size of a UUID is 128 bit, most of the time a 16 or 32 bit integer will be enough, then the
index leaves are smaller, more in the same page, etc.
I agree however that all these differences will not have a dramatic impact.
--
_______________________________________
REUSE CODE! Use custom tags;
See http://www.contentbox.com/claude/customtags/tagstore.cfm
(Please send any spam to this address: [EMAIL PROTECTED])
Thanks.
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
