Larry,

I don't believe the comparisons for GUIDs is a dtermining factor anymore in 7/2000. The only noticeable difference I see between using GUIDs and using integers how long it takes to return the data. The comparison itself is very fast.

>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.