Bei meiner Arbeit verwenden wir UUID als PKs. Was ich Ihnen aus Erfahrung sagen kann, ist, VERWENDEN SIE SIE NICHT als PKs (übrigens SQL Server).
Es ist eines dieser Dinge, dass es in Ordnung ist, wenn Sie weniger als 1000 Platten haben, aber wenn Sie Millionen haben, ist es das Schlimmste, was Sie tun können. Wieso den? Da UUIDs nicht sequenziell sind, muss MSSQL jedes Mal, wenn ein neuer Datensatz eingefügt wird, auf die richtige Seite schauen, um den Datensatz einzufügen, und dann den Datensatz einfügen. Die wirklich hässliche Folge davon ist, dass die Seiten am Ende alle in unterschiedlichen Größen und fragmentiert sind, also müssen wir jetzt regelmäßig defragmentieren.
Wenn Sie ein Autoinkrement verwenden, geht MSSQL immer zur letzten Seite, und Sie erhalten (theoretisch) gleich große Seiten, sodass die Leistung zum Auswählen dieser Datensätze viel besser ist (auch weil die INSERTs die Tabelle/Seite nicht blockieren für Bis dann).
Der große Vorteil der Verwendung von UUID als PKs besteht jedoch darin, dass es beim Zusammenführen keine Konflikte gibt, wenn wir Cluster von DBs haben.
Ich würde folgendes Modell empfehlen:1. PK INT Identität2. Zusätzliche automatisch generierte Spalte als UUID.
Auf diese Weise ist der Zusammenführungsprozess möglich (UUID wäre Ihr ECHTER Schlüssel, während der PK nur etwas Temporäres wäre, das Ihnen eine gute Leistung verleiht).
HINWEIS:Dass die beste Lösung darin besteht, NEWSEQUENTIALID zu verwenden (wie ich in den Kommentaren sagte), aber für Legacy-Apps mit nicht viel Zeit zum Refactoring (und noch schlimmer, die nicht alle Inserts kontrollieren) ist dies nicht möglich. Aber in der Tat Ab 2017 würde ich sagen, dass die beste Lösung hier NEWSEQUENTIALID ist oder Guid.Comb mit NHibernate macht.
Hoffe das hilft
