Guid vs INT - Quel est le meilleur en tant que clé primaire?

J'ai lu autour des raisons d'utiliser ou non Guidet int.

intest plus petit, plus rapide, facile à retenir, conserve une séquence chronologique. Et pour ce Guidqui est du seul avantage que j’ai trouvé, c’est que c’est unique. Dans quel cas un Guidserait mieux que intet pourquoi?

D'après ce que j'ai vu, intil n'y a aucun défaut, si ce n'est la limite du nombre, qui dans de nombreux cas est sans importance.

Pourquoi exactement a été Guidcréé? En fait, je pense que cela a un but autre que celui de servir de clé primaire d'un simple tableau. (Un exemple d'application réelle utilisant Guidquelque chose?)

_{(Guid = UniqueIdentifier) ​​sur SQL Server}

Cela a été demandé dans Stack Overflow ici et ici .

Le post de Jeff explique beaucoup sur les avantages et les inconvénients de l'utilisation du GUID.

GUID Pour

• Unique sur chaque table, chaque base de données et chaque serveur
• Permet de fusionner facilement des enregistrements de différentes bases de données
• Permet une distribution facile des bases de données sur plusieurs serveurs
• Vous pouvez générer des identifiants n'importe où, au lieu d'avoir à aller à la base de données
• La plupart des scénarios de réplication nécessitent quand même des colonnes GUID

GUID Contre

• C'est quatre fois plus grand que la valeur d'index classique à 4 octets; cela peut avoir de graves conséquences sur les performances et le stockage si vous ne faites pas attention
• Encombrant à déboguer ( where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
• Les GUID générés doivent être partiellement séquentiels pour newsequentialid()optimiser les performances ( sur SQL Server 2005+, par exemple) et pour permettre l'utilisation d'index en cluster.

Si vous êtes certain des performances et que vous ne prévoyez pas de répliquer ou de fusionner des enregistrements, utilisez int-le et définissez-le comme une incrémentation automatique ( graine d'identité dans SQL Server ).

Si vous synchronisez vos données avec une source externe, un GUID persistant peut être bien meilleur. Un exemple rapide d'utilisation d'un GUID est un outil envoyé au client pour analyser son réseau et effectuer certaines classes de détection automatique, stocker les enregistrements trouvés, puis tous les enregistrements du client sont intégrés dans une base de données centrale. retour sur notre fin. Si nous utilisions un entier, nous aurions 7 398 "1", et il serait beaucoup plus difficile de savoir lequel "1" était lequel.

J'ai utilisé une approche hybride avec succès. Les tables contiennent à la fois une idcolonne d' entier de clé primaire à incrémentation automatique ET une guidcolonne. Le guidpeut être utilisé selon les besoins pour identifier globalement la ligne de manière unique et idpeut être utilisé pour les requêtes, le tri et l'identification humaine de la ligne.

Certaines pratiques recommandées mentionnent encore que vous devez utiliser un type de données qui héberge avec le moins de mémoire possible l’ensemble des valeurs que vous allez utiliser. Par exemple, si vous l'utilisez pour stocker le nombre d'employeurs dans une petite entreprise et que vous n'atteignez probablement pas 100, personne ne suggérera alors d'utiliser une valeur bigint alors que int (même de petite taille) ferait l'affaire.

Bien entendu, l’inconvénient est que «Dites non à l’évolutivité!

De plus, je sais que ce n'est pas totalement lié, mais il y a un autre facteur à ce sujet. Lorsque cela n’est pas excessif, j’essaie généralement de recommander l’utilisation d’une clé primaire non générée automatiquement, si cela a du sens. Par exemple, si vous enregistrez les informations du conducteur, ne créez pas une nouvelle colonne générée automatiquement pour "ID", utilisez simplement le numéro de licence.

Je sais que cela semble vraiment évident, mais je vois cela être oublié assez souvent.

Pour le contexte: cette partie de la réponse a été abordée à partir d’une approche théorique des données, dans laquelle vous souhaitez que votre PC soit l’identificateur de données unique d’un enregistrement. La plupart du temps, nous créons ceux qui existent déjà, d'où la réponse précédente.

Cependant, il est très rare que vous puissiez avoir un contrôle étroit sur ces points de données et, par conséquent, vous devrez peut-être apporter des corrections ou des ajustements. Vous ne pouvez pas faire cela avec des clés primaires (enfin, vous le pouvez, mais cela peut être pénible).

Merci @VahiD pour les éclaircissements.

L'utilisation d'identifiants d'incrémentation automatique peut entraîner la fuite d'informations sur votre activité. Si vous exploitez un magasin et utilisez order_idpour identifier publiquement un achat, tout le monde peut connaître votre nombre mensuel de ventes à l'aide d'une simple arithmétique.

Une autre chose avec la façon dont les GUID sont générés. mrdenny a correctement fait remarquer que même si newsequentialid () est utilisé, le redémarrage des instances fait en sorte que les nouvelles valeurs commencent par les "trous" laissés dans le traitement précédent. Une autre chose qui affecte les GUID "séquentiels" est la carte réseau. Si je me souviens bien, l'UID de la carte réseau est utilisé dans le cadre de l'algorithme GUID. Si une carte réseau est remplacée, rien ne garantit que l'UID sera une valeur plus élevée pour conserver l'aspect séquentiel des choses. Je ne sais pas non plus comment plusieurs cartes d'interface réseau peuvent affecter l'affectation de valeurs à l'aide de l'algorithme.

Juste une pensée et j'espère que je me souviens bien. Passez une bonne journée!

Utilise les deux

Utilisez int / Bigint pour la clé primaire car il est facile à gérer et à utiliser comme relation de clé étrangère.

Mais lier une colonne au GUID afin que chaque ligne ait également une colonne unique