UUID
retourneert een universele unieke identifier
(hopelijk ook uniek indien ook geïmporteerd in een andere DB).
Om te citeren uit MySQL-document (nadruk van mij):
Aan de andere kant een eenvoudig INT primaire id-sleutel (bijv. AUTO_INCREMENT ) retourneert een uniek geheel getal voor de specifieke DB en DB-tabel, maar die niet universeel uniek is (dus als geïmporteerd naar een andere DB is de kans groot dat er primaire sleutelconflicten zullen zijn).
Wat de prestaties betreft, zou er geen merkbaar verschil moeten zijn bij het gebruik van auto-increment via UUID . De meeste berichten (inclusief enkele van de auteurs van deze site) vermelden dit als zodanig. Natuurlijk UUID kan wat meer tijd (en ruimte) kosten, maar dit is geen prestatie-bottleneck voor de meeste (zo niet alle) gevallen. Een kolom hebben als Primary Key moeten beide keuzes gelijk maken aan de prestaties. Zie onderstaande referenties:
- Naar
UUIDof niet naarUUID? - Mythen,
GUIDvsAutoincrement - Prestaties:
UUIDvsauto-incrementin cakephp-mysql UUIDprestaties in MySQL?- Primaire sleutels:
IDs versusGUIDs (codeer horror)
(UUID vs auto-increment prestatieresultaten, aangepast van Mythen, GUID vs Autoincrement
)
UUID voors / tegens (aangepast van Primaire sleutels:ID s versus GUID s
)
Opmerking
Ik zou de genoemde referenties aandachtig lezen en beslissen of ik UUID . wil gebruiken of niet, afhankelijk van mijn gebruik. Dat gezegd hebbende, in veel gevallen UUID s zou inderdaad de voorkeur hebben. Men kan bijvoorbeeld UUID . genereren s zonder gebruik te maken van/toegang te krijgen tot de database, of zelfs UUID . te gebruiken s die vooraf zijn berekend en/of ergens anders zijn opgeslagen. Bovendien kunt u eenvoudig uw databaseschema en/of clusterschema generaliseren/updaten zonder dat u zich zorgen hoeft te maken over ID s breken en conflicten veroorzaken.
In termen van mogelijke botsingen, bijvoorbeeld met behulp van v4 UUIDS (willekeurig), de kans om een duplicaat te vinden binnen 103 biljoen versie-4 UUID's is één op een miljard.