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.

>>GUID is good, but it have 32 bytes length compare to the integer (4 bytes). For large tables this is significant slow down and extra data.
>
>Vlad,
>GUIDs can be implemented under SQL Server 7/2000 as a UniqueIdentifier data type. As such, they are a 16 byte integer (not 32) so there is really no significant performance hit using them in large tables. If they are implemented as a CHAR type, then I agree that there is a performance hit.