Travis,
Okay, you got me. I didn't take the process out to its conclusion. Let's break it down.

IIRC, when SQL Server compares character expressions it compares it one character at a time. So for very long expressions (e.g. 36 character GUIDs), this is a serious performance hit. This was true in 6.5 so I don't know if it's still the case in 7/2000. With an integer (4 byte or 16 byte), the comparison can be done in one operation. So I still say there is no significant performance hit there.

The hit comes when SQL Server must return all the rows it has found that match the query. If it has to return more pages then it takes longer. I see your point how using GUIDs would affect this process.

>Larry,
>
>I have to disagree with you on this one. If you have GUIDs within a table, let's say 4, you're looking at 64 bytes worth of space for those 4 fields versus 16 for 4 integer fields. Keep in mind that SQL Server only allocates 8096 bytes of useable space per page.
>
>To use GUIDs, each row would take up (4 bytes * 16 bytes) + 10 bytes or 74 bytes total per row. That means SQL Server will only be able to fit 109 rows per page. (SQL Server will not store partial rows on a page)
>
>On the other hand, to use integers, each row would take up (4 bytes * 4 bytes) + 10 bytes or 26 bytes total per row. In this case, SQL Server will be able to fit 311 rows per page. Almost 3 times as many.
>
>Now I know my example is very simple, but I think you get my point. You have to be very careful choosing the correct data type to use as keys in your databases. If you have a table that has only 2 of those fields (1 primary key and 1 foreign key), then with all the other fields added in, you probably won't loose that much storage space. However, for databases with tables that have a significant amount of foreign keys, this will quickly become an issue.
>
>Just my 2 cents.