note : you will have a problem when you want to create a clustered index on an already populated table.... you have to copy the data out, truncate, create clustered index and then copy the date back in.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 21 January 2003 13:24 To: SQL Subject: RE: Data storage best practice For anyone else that might find it useful, I was taught to create my indices this way: 1. Declare primary key constraints. In some DBMS's, the primary key constraint is automatically created as a clustered, unique index. In SQL Server, you can choose whether to make it clustered or not. Regardless, your primary key column(s) are always indexed. 2. Declare unique indices on alternate keys. 3. Declare clustered indices on tables for whose columns you will have a large number of rows and where you can clearly define the columns as having a wide range of queries. 4. Declare non-clustered indices on tables where you have non-key columns that will be part of ad hoc joins. 5. Test and tune your index scheme by populating the dB with test data of the appropriate scale, starting a trace, and then running a battery of stress tests against the dB. Microsoft's index tuning wizard can help in this process, but cannot substitute for raw benchmarking. If you put it off long enough, it might go away. -- Unknown ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=6 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=6 Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
