On Thu, 2004-08-26 at 12:30, Magnus Hagander wrote: > Almost the same for MSSQL. The clustered index is always forced unique. > If you create a non-unique clustered index, SQLServer will internally > pad it with random (or is it sequential? Can't remember right now) data > to make each key unique. The clustered index contains all the data > fields - both the index key and the other columns from the database. > > It does support non-clustered indexes as well on the same table. Any > "secondary index" will then contain the index key and the primary key > value. This means a lookup in a non-clustered index means a two-step > index lookup: First look in the non-clustered index for the clustered > key. Then look in the clustered index for the rest of the data.
Ah, okay. I see how that would work for a secondary index, though it would make for a slow secondary index. Neat workaround. For all I know, current versions of Oracle may support secondary indexes on index-organized tables; all this Postgres usage over the last couple years has made my Oracle knowledge rusty. > IIRC, SQL Server always creates clustered indexes by default for primary > keys. That would surprise me actually. For some types of tables, e.g. ones with multiple well-used indexes or large rows, index-organizing the heap could easily give worse performance than a normal index/heap pair depending on access patterns. It also tends to be more prone to having locking contention under some access patterns. This is one of those options that needs to be used knowledgeably; it is not a general architectural improvement that you would want to apply to every table all the time. J. Andrew Rogers ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly