I’ve had multiple folk approach me as to why I use GUIDs almost exclusively in database and other persistent storage solutions while designing systems. And well the answer is in the name – GUID = Global Unique Identifier.
The fact is that typically when we persist an object to storage we are really persisting an instance of an object and although we humans like to identify things by name, sometimes an instance of an object does not have a unique human name (think telemetry, statistics, locations of data). The big point is that even if a objects seems to have a human readable unique name (Uri, FQN, Mount point), by utilizing the unique name as an identifier of an instance, you have not imposed business specific logic in your storage of said object.
As software engineers we all know that change requests come just about every week 🙂 . And event though we can’t think of a reason why a web page object should not be stored with the Uri as the unique key (because well maybe it is) I would argue that it’s still better to store records with a unique key such as a GUID. Take for example when, one month after releasing no less, you get a request to add page versioning. Now, if we choose to use the business logic instance of something (a page) to store our data we would have to fundamentally change how we store and process this data. If we had chosen to utilize a GUID instead, we would only need to make slight adjustments to how we retrieve data to , for example, pull the latest version.
Additionally GUIDs are very handy in a development, integration, production lifecycle as objects are unique event amongst environments, but more on that later.