>>Another thing: using integers as primary keys gives complex queries an inherent speed boost. This alone is enough argument to use surrogates.
>
>After an example presented by Daniel Rouleau in another thread, I have changed my position to use surrogate keys most of the time, not all. He presented what I consider a good example of when to use intelligent keys.
>
>And one problem with integers, at least in SQL Server 7, is that you only have around 2 billion. This works fine for most situations (at least mine), but what happens after that? I think this changes in SQL Server 200.

SQL Server 2000 does fix that by expanding the length of integer fields. But I am not sure if the same rule applies in SQL Server. The index engine in SQL Server is different. It makes sense that the smallest footprint would be the fastest, but have any test been done like thod Mac Rubel did?