I like them.
And yes, those 8-4-4-4-12 character groups are a traditional GUID.
They have some useful attributes. They are particularly useful for Master Data, which “Brand” might just be. More on that below.
The “G” in GUID is really “Global”. In other words, a GUID entry for a specific ActiveX component in the Windows registry can be used anywhere in the world without worrying about namespace collisions. Likewise, a primary key from a Person table can be copied and swapped everywhere without any concern for mixing it up with another different person.
The Wikipedia article discusses some of the algorithms in use to guarantee they are global. One common one used is to mix in some machine-specific identifier (though there are privacy concerns to consider with that).
Because they are global, you don’t need to retain type information along with them in your workflow. Of course, it does help if you know you are moving Employee records around or Document records around, but it isn’t necessary.
In a traditional database you might have identifiers like “655321” and “102314”, but in order for those numbers to be useful you need to know that “655321” is a PERSON_ID and “102314” is a DOCUMENT_ID.
Consequently, if you had some kind of table, say OBJECT_ANNOTATIONS, which had text entries annotating any kind of data in your database, you would need both OBJ_KEY and OBJ_TYPE columns to uniquely identify the table and key for the annotation (if you have Document 101 and Person 101, you need to include the type to uniquely identify the correct annotation). With a GUID, you have no need to indicate OBJ_TYPE. Your annotation table could consist of OBJ_GUID,ANNOTATION. And for any object in your database you could look up its GUID in the annotations table to see if any are present. This is a contrived example, but it shows some of the use of global uniqueness.
Global uniqueness is useful in data warehousing.
In a very large corporate database environment, it is not unusual to have many layers of databases, with data originating in transactional systems, moving to databases of Master Data that then feed a data warehouse that then feeds data marts that then feed other transactional systems. Such master data concepts as “Employee” cut across the corporation and these records find themselves being passed around like baseball cards in dozens of different databases.
Business keys (the unique key formed by the data elements themselves) are not sufficient for identifying duplicates because they change. For example, employees get married and change their names. An illustration of this weakness, especially in disconnected data warehousing environments: Imagine if I sent you two letters, the first saying “Jane Smith is now Jane Doe”, followed by “Jane Doe is now Jane Johnson” and you missed the first… you would not be able to make the second change.
Technical keys, or surrogate keys, are sometimes troublesome because these are usually different for each database (especially so across Dev/Test/Prod environments)
Here is were GUIDs can make a difference. As long as the architecture is configured correctly, a GUID can be used to identify master data in different parts of the organization.
In your example, I could have a database right now where I enter BRAND_GUID=“9117FC47-51B2-47B6-A79F-F6FB9988C550”
Regardless of what I called it, someone could copy this GUID from my post and look in your company’s database and unambiguously identify the precise brand you copied that from. And, as I said earlier, “Brand” sounds like a pretty good candidate for Master Data that would be proliferated throughout the corporation.