GUIDs are not completely random. That’s not a surprise to me. What is a surprise to me is that the thirteenth character, the first one after the second dash, in probably every context I’ve ever used GUIDs, is always the number 4. I learned this just today. Just now researching for this article.
GUIDs are not completely random. That’s not a surprise to me. What is a surprise to me is that the thirteenth character, the first one after the second dash, in probably every context I’ve ever used GUIDs, is always the number 4. I learned this just today. Just now researching for this article.
The sky is full of 4s
- Let’s back up. What is a GUID? It stands for “Globally Unique Identifier.” Most people pronounce it “goo-id” like “druid”, but I pronounce it “gwid” like “squid” and always hope it catches on. I’ve been using GUIDs so extensively for decades and must speak the word so much I decided I don’t have time for two syllables.
A GUID is a string of 32 alphanumeric characters always separated in the same place with three dashes like this one:
4f13d8a3-50b2-4a1d-a1a1-8570d30aa3e7
Or this one:
edd6fa1a-6881-4901-97ab-26e06f63f0bd
Have at it yourself, make all the GUIDs you want at a website like “Online GUID / UUID Generator” https://www.guidgenerator.com/online-guid-generator.aspx
They aren’t completely random letters and numbers, however they are random enough that you’re extremely unlikely to generate the same GUID twice. The number of possible variations of GUIDs, at least the version I use, is 5 with 36 zeros after it. The number of stars in the universe is approximately 10 with 23 zeroes after it, meaning there are more GUIDs than stars in the universe.
So why is this useful? Let’s first discuss a problem we have in SharePoint when creating data relationships.
A common data relationship is one-to-many or a parent-child relationship where we have one parent record and many child records associated with it. An example is an expense report with multiple line items. You might have an expense report for September 2022 with 10 line items of business supplies, meals, and other charges you need to report to your company. In October you have another expense report with another 7 items.
In a relational database you might name a table ExpenseReports and another table Expenses. The ExpenseReports table would contain your September and October expense report information (like your name and department) and the Expenses table would contain the 17 line items spanning both reports. The ExpenseReports table would include an ID, let’s say ID 1 and ID 2. And the Expense table has both its own ID column, some other information like amount (cost), quantity, and a column called a foreign key possibly named ExpenseReportsID that connects each line item to the related report.
An ExpenseReports table and Expenses table in SQL Server
If you build a custom application using a database like this, a user can enter a new expense report, say December, enter their name and department, and then start to fill in the expenses one at a time. When the user clicks OK or Save, the database has a way to provide the ID for the ExpenseReports record to the Expenses table so that it can be used for the ExpenseReportsID value.
If we want to create a similar relationship in SharePoint, we use lists instead of tables: an ExpenseReports list and an Expenses list. We could use similar columns, including an ExpenseReportsID column in the Expenses table.
In the same user scenario, a new expense report can be entered into a Nintex form, and using whatever method, new expense line items can be added. But when the user clicks OK or Save there is a problem: SharePoint doesn’t provide a way to give the parent list’s ID to the child list item. In fact, SharePoint itself doesn’t know what the ID is going to be until the expense report is saved to SharePoint. You can guess that it’s usually going to be the next number in sequence: if 1, 2, and 3 were already used for September, October, and December’s expense reports you might guess 4 will be used for January. But what if another user beat you to it and entered their own January report and used ID 5? Then yours might be ID 6. Notice this is only a problem when the user is creating a new expense report and adding expenses at the same time. An existing, already-saved expense report won’t have this problem.
The whole reason SharePoint list item IDs are increased by one is so that they don’t (and can’t) repeat. SharePoint guarantees the ID will be unique so that it can be used, well, as an identifier.
So here is where the GUID comes in. Since a GUID is random* it’s not in any predictable sequence, however it has the advantage that it doesn’t matter what is generated: it will still be unique. In our SharePoint application new-expense-report scenario, the expense report can create its own ID (a GUID) and give it to the expenses list item. The SharePoint ID can just be ignored.
The implementation can be one of several ideas I’ve explored and have posted about, or other ideas I haven’t considered. But one way or another, via a pop-up child form, passed in a URL, in some JavaScript behind a button, or using the TekDog Productivity Controls subform, the parent GUID can be passed to the child list item and create the data relationship.
The TekDog Productivity Controls Subform connecting a Recipes parent list item to Ingredients child list items using GUIDs
The Ingredients list uses GUIDs to relate to the Recipes list with a foreign key and also uses GUIDs for each list item’s unique identifier
I’ve been using GUIDs for years and have surely generated thousands, or created software that generated hundreds of thousands, maybe millions of GUIDs for some clients. I never noticed that the one character was always 4 and my mind is blown.
Also, the seventeenth character, the one after the third dash, is always 8, 9, a, or b. At least for the commonly used GUID variant I’ve been using.
*mostly
.