>>><snip>
>>>>I'd bet that a clustered index is something that the SQL group could happily do without.
>>>
>>>Jim,
>>>
>>>How did you come to this conclusion?
>>
>>Just *my* opinion based on how I see such logic working and the probable wide variability of response times that might be exhibited depending on how much of the cluster is being updated when and where and by simultaneous activity.
>>Whenever you have to move records around dynamically it's simply gotta be a real pain to track and awfully dangerous too.
>>
>>As I said in my original, just ONE opinion.
>>
>>cheers
>
>Jim,
>
>Looks like your opinion is based on the total misunderstanding how clustered index works. There's no need for SQL Server to move any records around when records added or updated. I would recomend you to read the book Inside SQL Server 2000 by Kalen Delaney which explains it in details.

And F*CK YOU too, Sergey.
I took my **opinion** from my reading of "Inside SQL Server 7.0" and a quick re-check still has me with the same OPINION. There, under "Clustered Indexes" "The leaf level of a clustered index contains the data pages, not just the index keys. A clustered index keeps the data in a table physically ordered around the key...". And on the next page, under "Creating Indexes", in a discussion of "FILLFACTOR" "FILLFACTOR lets you reserve some space on each leaf page of an index. (In a clustered index, this equals the data page.) By reserving some free space with FILLFACTOR, you can later avoid the need to split pages to make room for an entry..".

My limited reading capability interpreted the above as follows:
1) There are times when page splitting must be done and the best that FILLFACTOR does is to reduce the occurrance of such events.
2) Since clustered indexes are kept PHYSICALLY ORDERED around the key AND the KEY IS WITH THE DATA, then it follows in my mind that when ANY page splits are necessary for a clustered index, then RECORDS HAVE TO BE MOVED.

Seems pretty sensible to me.