I guess that you're gonna stay confused, Gunnar. Seems the authority doesn't like the stronger form of what he serves himself.

**MY** take, from reading the (admittedly older) book, is that LEAF INDEXES AND DATA reside together on the same data page. This makes it fastest because when the leaf index is read THE DATA IS READ TOO. No other form of SQL Server index (seems to) has such a quality.

I can see no way it would be faster than anything else if this wasn't the case.

Yes, I believe that, because writing could involve re-writing of data TO KEEP THE INDEXES (thus data) IN ORDER, that performance could be erratic DEPENDING ON WHAT/HOW MUCH/BY HOW MANY/WHEN/etc. I'm quite sure this could be minimized by over-allocation FILL to reduce the re-writes.




>OK, I am realy confused now!
>
>Reading the rest of the posts, you guys are talking about a clustered index beeing the fastest way in retriving data.
>
>but if i understand you all correct it also would be the slowest when adding new recordas to the table (especially on large tables).
>
>so it sounds to me that unless you already have a table witch will never grow, then the clustered index is great, but on a 'normal' table which will be added to, it's not a smart setup?!
>
>as you can gues, i have never worked with sql server, but eventually whant to learn it.
>
>>Well I'd consider it more akin to the old "INSERT" (not the INSERT - SQL) command of VFP with the difference that in the case of SQL Server it does leave some empty spots throughout the table in anticipation of new records coming in sooner or later.
>>
>>[The old INSERT command actually inserts the record into the specific place that you told it to, recopying the old records after the new one to make room for it. Not a great technique, speed-wise.]
>>
>>
>>>hmm, isn't that then like a continues 'sort to' command from fox?
>>>
>>>
>>>>At least for SQL Server, a clustered index, simply put, is an 'index' (one only) where the data is physically stored in the correct index order AND the index is in the leaf node WITH THE DATA.
>>>>
>>>>Since data can be **physically** ordered by only 1 index, there can be only 1 clustered index per table. The table can have oodles of other indexes.
>>>>
>>>>
>>>>Gotta be a real bear to 'maintain'.
>>>>
>>>>
>>>>cheers
>>>>
>>>>>hello Jim
>>>>>
>>>>>what exactly is a clustered index?
>>>>>
>>>>>>While I think the VFP Team could, I'd have to ask why it should?
>>>>>>
>>>>>>I see little benefit and LOTS of potential trouble with doing so. Sometimes "nifty" ideas are just that - ideas... and sould be left that way.
>>>>>>I'd bet that a clustered index is something that the SQL group could happily do without.
>>>>>>
>>>>>>Just one opinion.
>>>>>>
>>>>>>>Well !!
>>>>>>>
>>>>>>>In the Fox it has as to create Cluster Index ?
>>>>>>>
>>>>>>>Thank all
>>>>>>>
>>>>>>>Lázaro Santos.