| Line 9: | Line 9: | ||
==== Context-Agnostic ==== | ==== Context-Agnostic ==== | ||
GUIDs are not tied to a specific product or domain. They can be used for people, cars, files, webpages, colors, or anything else. Context determines the meaning of a GUID. | GUIDs are not tied to a specific product or domain. They can be used for people, cars, files, webpages, colors, or anything else. Context determines the meaning of a GUID. | ||
==== Usage ==== | |||
GUIDs are commonly used in databases, software interfaces, sessions, and more. They provide a unique serial number applicable to any item. | |||
==== Advantages ==== | ==== Advantages ==== | ||
No central authority is needed for GUID management. In a standard MDriven created database each row is assigned a GUID. This makes object identity certain and makes creating APIs and connecting different databases together much easier. This means, for example, that two | No central authority is needed for GUID management. In a standard MDriven created database each row is assigned a GUID. This makes object identity certain and makes creating APIs and connecting different databases together much easier. This means, for example, that two user objects created in two different systems can be told apart even with all other data is the same. | ||
Have a GUID on each object is not a requirement, but is strongly encouraged. | Have a GUID on each object is not a requirement, but is strongly encouraged. | ||
==== Warning when designing databases ==== | ==== Warning when designing databases ==== | ||
NEVER include a GUID in a database index. Because they are all unique, they can't be efficiently indexed. That's why | NEVER include a GUID in a database index. Because they are all unique, they can't be efficiently indexed. That's why a MDriven database uses easy to index integers for connecting tables with primary and foreign keys. Those Integer key values should be kept inside each database, not to be used outside a database instance. When transferring data between systems, either by copying or APIs, always use the GUID, not the row ID integer for object (row) identfication. | ||
[[Category:TOC]] | [[Category:TOC]] | ||
Revision as of 10:26, 26 April 2024
What is a GUID?
A GUID (Globally Unique Identifier) is a 128-bit integer used to uniquely identify resources.
It is usually represented as a sequence of 32 hexadecimal digits grouped into chunks (e.g., 30dd879c-ee2f-11db-8314-0800200c9a66). The format consists of 8-4-4-4-12 segments.
Uniqueness and Size
GUIDs are enormous numbers, practically guaranteed to be unique. They provide approximately 2^128 (about 10^38) possible values. This vast range ensures that collisions (two identical GUIDs) are all but impossible to occur.
Context-Agnostic
GUIDs are not tied to a specific product or domain. They can be used for people, cars, files, webpages, colors, or anything else. Context determines the meaning of a GUID.
Usage
GUIDs are commonly used in databases, software interfaces, sessions, and more. They provide a unique serial number applicable to any item.
Advantages
No central authority is needed for GUID management. In a standard MDriven created database each row is assigned a GUID. This makes object identity certain and makes creating APIs and connecting different databases together much easier. This means, for example, that two user objects created in two different systems can be told apart even with all other data is the same.
Have a GUID on each object is not a requirement, but is strongly encouraged.
Warning when designing databases
NEVER include a GUID in a database index. Because they are all unique, they can't be efficiently indexed. That's why a MDriven database uses easy to index integers for connecting tables with primary and foreign keys. Those Integer key values should be kept inside each database, not to be used outside a database instance. When transferring data between systems, either by copying or APIs, always use the GUID, not the row ID integer for object (row) identfication.