It has always been my opinion and understanding that the best way to build a table is to start with an integer identity column and make that the primary key and also the clustered index. The logic, as I understand it, is that the primary key and clustered index, being fundamental to good performance, will then work best with non-clustered indexes added, as the clustered index key is always added to any non-clustered indexes meaning that 2 look-ups are always required to find rows, the first to get the collection of keys for the clustered index then return the rows from the clustered index.Recently I have had that methodology questioned, the suggestion being that identity columns are a waste of space and that the clustered index should be as fat as it needs to be so that all rows in the table are therefore ordered by that index, and as long as the queries are following the same basic structure no other indexes are required, leading to efficiencies because any look-ups are just a single look-up from the clustered index, also primary keys are not essential so there fore the clustered index does not need to be unique.I should also point out that the institution that I am working at at the moment uses SQL Server standard edition, for both production and development, these are both data warehouse servers, so the databases are all running in simple recovery model. The particular table that has raised this issue is very large currently containing 1,060,167,492 rows meaning that additional indexes create a large overhead in space and CPU time in maintaining it. It would also be good to get any opinion on whether better performance could be expected by upgrading to enterprise edition, apart from the obvious option of partitioning that tableI would really appreciate anyone else's opinion
↧