Mark Breen
marklbreen at gmail.com
Wed Dec 16 03:29:26 CST 2009
Hello John, It is really going to be the best solution to index every column? Are you really using all columns to search on? I instinctively feel that if you place an index on every column, you will loose the benefits of having an index in the first place, or at least you loose some of the benefits that a neat and quick index delivers. I am imagining Encyclopedia Brittanica if it supplied 25 different indexes, the indexes would be larger that the books. I always imagined we should have as few indexes as you can get away with but as many as we need. In the case where you have an order for a specific column(s), can you not programatically create the indexes on those columns, then run your queries and perhaps even go the final step and drop those indexes you just created after the order has been delivered. And if it does not take too long, I would run the scripts that the maintenance wizard create afterwards everytime also, in the hope that it keeps the database intact. Again, this is just instinct, but I feel you will have other integrity / file size / performance /de-fragmentation / torn pages etc etc with such enormous data and enormous numbers of indexes. What do you think? Mark 2009/12/16 jwcolby <jwcolby at colbyconsulting.com> > Well, I just discovered my reason to update to SQL Server 2008. > > 2005 has a maximum number of non-clustered indexes per table of 250. SQL > Server 2008 has a maximum > of 999. I have 584 fields that I need to create indexes on. > > Time to do an install... > > ;) > > -- > John W. Colby > www.ColbyConsulting.com > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > >