Dans mon travail, nous utilisons UUID comme PK. Ce que je peux vous dire par expérience, c'est NE PAS LES UTILISER comme PK (SQL Server en passant).
C'est une de ces choses qui, quand vous avez moins de 1000 enregistrements, c'est bien, mais quand vous avez des millions, c'est la pire chose que vous puissiez faire. Pourquoi? Étant donné que les UUID ne sont pas séquentiels, chaque fois qu'un nouvel enregistrement est inséré, MSSQL doit consulter la bonne page pour insérer l'enregistrement, puis insérer l'enregistrement. La conséquence vraiment laide avec cela est que les pages se retrouvent toutes dans des tailles différentes et elles finissent par être fragmentées, donc maintenant nous devons faire une défragmentation périodique.
Lorsque vous utilisez une auto-incrémentation, MSSQL ira toujours à la dernière page et vous vous retrouverez avec des pages de taille égale (en théorie), de sorte que les performances pour sélectionner ces enregistrements sont bien meilleures (également parce que les INSERT ne bloqueront pas la table/page pour si longtemps).
Cependant, le gros avantage d'utiliser UUID comme PK est que si nous avons des clusters de bases de données, il n'y aura pas de conflits lors de la fusion.
Je recommanderais le modèle suivant :1. PK INT Identité2. Colonne supplémentaire générée automatiquement en tant qu'UUID.
De cette façon, le processus de fusion est possible (UUID serait votre clé REAL, tandis que le PK serait juste quelque chose de temporaire qui vous donne de bonnes performances).
REMARQUE :la meilleure solution consiste à utiliser NEWSEQUENTIALID (comme je le disais dans les commentaires), mais pour les applications héritées avec peu de temps pour refactoriser (et pire encore, ne contrôlant pas toutes les insertions), il n'est pas possible de le faire. Mais en effet à partir de 2017, je dirais que la meilleure solution ici est NEWSEQUENTIALID ou faire Guid.Comb avec NHibernate.
J'espère que cela vous aidera
