Home/ Questions/Q 175123
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T13:38:37+00:00

I’ve been investigating the use of GUIDs as primary keys in databases. So far,

  • 0

I’ve been investigating the use of GUIDs as primary keys in databases. So far, the pros seem to outweigh the cons. However, I see one point where GUIDs may not be what I want.

In my application, users should be able to identify objects based on a user-friendly ID. So, for example, if they want to get a specific product without typing in the full name, they can use the product’s ID. GUIDs aren’t easy to remember for something like that.

The solution I’ve been thinking about is to use both a GUID and an auto-incrementing integer. The GUID would be the row’s primary key, while the auto-incrementing integer would be an index used by the application’s filtering functions. All SQL SELECT, UPDATE, DELETE statements would use the GUID, however.

The main reason I want to use GUIDs is to prevent clashes when merging two databases. If Database #1 and Database #2 both have a Product #2, the importer script would have to change the ID and all foreign keys referring to it. With GUIDs, I only have to change the user-friendly ID in the table itself, while foreign keys would use the GUID unique to each imported record and will therefore work without modification.

So, my question is: are there any major problems (besides the size of the GUID field and easy page fragmentation) with having an auto-incrementing integer index and a GUID primary key?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. I always tend to use surrogate primary keys in my database. That is: those primary keys have no actual meaning in the problem domain, and thus, those primary keys are never exposed to users. (If this surrogate primary key is of type GUID or an identity, I don’t care; this depends on the requirements).

    If you say that users should be able to identify objects based on a user-friendly ID, then, I think that this user-friendly ID is a value that belongs to your ‘problem domain’. This means, that this ID should indeed be an attribute in your table, but it should not be used as the primary key in your table.

    This also allows you to easily modify the value of such an user-friendly ID (if that should be necessary), without you having to worry about modifying related foreign keys as well.

    • 0