I recently learned about how relationships are defined in the database at work, and was wondering if this is a standard practice.
Let's say we have two processes: Process A, and Process B. Process B depends on the results from Process A, so there is a relationship that needs to be defined between a Process B run and a Process A run. This is how the relationship is defined:
TableProcessA:
Id
and
TableProcessB:
Id
ProcessAId
Now, up to this point, things make sense to me, but then things get a little strange to me and my understanding of table design. Whenever a row is created in TableProcessA or TableProcessB, a function is called that creates a globally unique id for each. So basically, all of the Id fields in TableProcessA and TableProcessB will not contain any matches because the Id's are not just unique to its table, but to the entire database.
My question is, how standard is this? I was brought up on the idea that each table should simply have an autoincrementing id that is unique just to the table and not the entire database.
Best Answer
This isn't that weird a practice. Those are called GUIDs, or Globally Unique IDs. The idea is that, given a GUID, you can tell exactly what piece of data the id belongs to because it will be unique everywhere. GUIDs are best used when you will be merging different sources of similar data; for example inventory for different stores.
I would do some research and find out as to why this is a common practice in your environment. Maybe it's needed, maybe it's not.