Comment aimez-vous vos clés primaires? [fermé]

https://stackoverflow.com/questions/404040

03-07-2019
|

Question

Lors d’une discussion animée au sein de mon équipe, j’ai été amené à penser à ce que la plupart des gens aiment comme clé primaire. Nous avons eu les groupes suivants -

Int / BigInt qui auto-incrémentent sont suffisamment bons clés primaires.
Il doit y avoir au moins 3 colonnes qui composent la clé primaire.
Les identificateurs d'identifiant, de GUID et de ligne lisibles par l'homme doivent tous être traités différemment.

Quelle est la meilleure approche pour les PC? Ce serait génial si vous pouviez justifier votre opinion. Y at-il une meilleure approche que ce qui précède?

EDIT: Quelqu'un a-t-il un exemple / algorithme simple pour générer des identifiants lisibles par l'homme pour les lignes qui évolue bien?

La solution

Si vous envisagez de synchroniser des bases de données avec des applications connectées occasionnellement, vous devez utiliser des GUID pour vos clés principales. C’est un peu pénible pour le débogage, c’est-à-dire que, mis à part ce cas, j’ai tendance à rester fidèle à cette intégrité automatique.

L'incrémentation automatique devrait être votre valeur par défaut, et ne pas leur utilisation devrait être justifiée.

Autres conseils

Je ne vois pas de réponse qui souligne (ce que je considère comme) le point réellement fondamental - à savoir qu'une clé primaire est ce qui garantit que vous n'obtiendrez pas deux entrées dans le tableau pour le même monde réel. entité (telle que modélisée dans la base de données). Cette observation permet d’établir quels sont les bons et les mauvais choix pour la clé primaire.

Par exemple, dans une table de noms et de codes d’États (américains), le nom ou le code peut être la clé primaire - ils constituent deux clés candidates différentes, et l’une d’elles (normalement la plus courte - le code) est choisi comme clé primaire. Dans la théorie des dépendances fonctionnelles (et des dépendances de jointure - 1NF à 5NF -, ce sont les clés candidates qui sont cruciales plutôt que les clés primaires.

Pour un contre-exemple, les noms humains font généralement un mauvais choix pour la clé primaire. Nombreux sont ceux qui se font appeler "John Smith". ou d'autres noms similaires; Même en prenant en compte les prénoms (souvenez-vous: tout le monde n’en a pas - par exemple, ce n’est pas le cas), les possibilités de duplication sont nombreuses. Par conséquent, les gens n'utilisent pas les noms comme clés primaires. Ils inventent des clés artificielles telles que le numéro de sécurité sociale (SSN) ou le numéro d'employé et les utilisent pour désigner l'individu.

Une clé primaire idéale est courte, unique, mémorable et naturelle. Parmi ces caractéristiques, l'unicité est obligatoire; les autres doivent faire face aux contraintes des données réelles.

Lorsqu'il s'agit de déterminer la clé primaire d'une table donnée, vous devez donc regarder ce que cette table représente. Quel ensemble ou ensembles de valeurs de colonne dans la table identifie de manière unique chaque ligne de la table? Ce sont les clés du candidat. Maintenant, si chaque clé candidate comprend 4 ou 5 colonnes, vous pouvez alors décider que celles-ci sont trop maladroites pour constituer une bonne clé primaire (principalement pour des raisons de brièveté). Dans ces circonstances, vous pouvez introduire une clé de substitution - un numéro généré artificiellement. Très souvent (mais pas toujours), un simple entier de 32 bits est suffisant pour la clé de substitution. Vous définissez ensuite cette clé de substitution comme clé primaire.

Cependant, vous devez toujours vous assurer que les autres clés candidates (la clé de substitution est également une clé candidate, ainsi que la clé primaire choisie) sont toutes conservées en tant qu'identificateur unique - normalement en plaçant une contrainte unique sur ces ensembles de colonnes.

Parfois, les gens ont du mal à identifier ce qui rend une ligne unique, mais il devrait y avoir quelque chose pour le faire, car répéter une information ne la rend pas plus vraie. Et si vous ne faites pas attention et obtenez deux lignes (ou plus) censées stocker la même information et que vous devez ensuite mettre à jour les informations, il existe un risque (surtout si vous utilisez des curseurs) de ne mettre à jour qu'une seule ligne. au lieu de chaque ligne, les lignes sont désynchronisées et personne ne sait quelle ligne contient les informations correctes.

C’est une vue assez dure, à certains égards.

Je n'ai pas de problème particulier à utiliser un GUID quand ils sont nécessaires, mais ils ont tendance à être gros (comme dans 16 à 64 octets), et ils sont utilisés trop souvent. Très souvent, une valeur parfaitement correcte de 4 octets suffirait. L'utilisation d'un GUID dans lequel une valeur de 4 octets suffirait gaspille de l'espace disque et ralentit même l'accès indexé aux données car il y a moins de valeurs par page d'index, de sorte que l'index sera plus profond et qu'il faudra lire plus de pages pour accéder à la page. informations.

Il ne s'agit que d'un problème religieux, car les gens recherchent une réponse universelle et juste. Le fait que votre équipe et ce fil de discussion SO manifestent tant de désaccord devrait indiquer qu'il existe de bonnes raisons d'utiliser toutes les solutions que vous décrivez, dans différentes circonstances.

Les clés de substitution sont utiles lorsqu'aucun autre attribut ou ensemble d'attributs de la table ne permet d'identifier les lignes de manière unique.
Il est préférable d'utiliser des clés naturelles pour rendre la table plus lisible par l'homme. Les clés naturelles permettent également à la clé étrangère d'une table dépendante de contenir une valeur réelle au lieu d'un identifiant de substitution. Par exemple. lorsque vous avez besoin de stocker state (CA, TX, NY), vous pouvez également utiliser une clé naturelle char (2) au lieu d'un int.
Utilisez des clés primaires composées, le cas échéant. Ne pas ajouter un " id " clé de substitution inutilement lorsqu'une clé composée parfaitement bonne existe (cela est particulièrement vrai dans les tables plusieurs-à-plusieurs). Un mandat pour une clé à trois colonnes dans chaque table est un non-sens absolu.
Les GUID sont une solution lorsque vous devez préserver l'unicité de plusieurs sites. Ils sont également pratiques si vous souhaitez que les valeurs de la clé primaire soient uniques, mais non ordonnées ni consécutives.
INT vs. BIGINT: il n'est pas courant qu'une table nécessite une plage de 64 bits pour les clés primaires, mais avec la disponibilité croissante de matériel 64 bits, cela ne devrait pas être un fardeau, et donne plus d'assurance que vous ne déborderez pas. INT est bien sûr plus petit, donc si l’espace est restreint, cela peut donner un léger avantage.

J'aime le blog du programmeur de base de données . en tant que source pour ce genre d’informations.

3 colonnes pour une clé primaire? Je dirais que les colonnes devraient avoir des contraintes uniques appropriées selon les règles métier, mais que je disposerais toujours d'une clé de substitution distincte. Les clés composées signifient que la logique métier entre dans la clé. Si la logique change, tout votre schéma est vissé.

J'aime le mien unique.

Je vais toujours avec la clé de substitution. Une clé de substitution (généralement une colonne d'identité, une auto-incrémentation ou un GUID) est une clé dans laquelle la clé n'est pas présente dans les données elles-mêmes. En revanche, une clé naturelle est une clé qui identifie de manière unique la ligne. Autant que je sache dans la vie, il n’existe pratiquement aucune vraie clé naturelle. Même des choses comme le SSN aux États-Unis ne constituent pas une clé naturelle. Les clés primaires composites sont une catastrophe imminente. Vous ne pouvez éditer aucune de ces données (ce qui est l'inconvénient majeur de toute clé naturelle, composite ou non), mais le pire est qu'avec une clé composite, vous devez maintenant perpétuer ces données de clé dans chaque table associée. Quel gâchis géant.

Maintenant, pour la sélection de la clé de substitution, je m'en tiens aux colonnes d'identité (je travaille principalement dans MS SQL Server). Les GUID sont trop volumineux et Microsoft recommande de ne pas les utiliser comme clé de contrôle. Si vous avez plusieurs serveurs, tout ce que vous avez à faire est d’augmenter l’incrément de 10 ou 20 ou peu importe le nombre maximum de serveurs que vous aurez besoin de synchroniser / développer, et simplement d’augmenter le germe de chaque table sur chaque serveur suivant. et vous n'aurez jamais de collision de données.

Bien sûr, en raison de l'incrément, je transforme la colonne d'identité en BigInt (autrement dit long [64 bits]).

Si vous faites un peu de calcul, même si vous augmentez l’incrément de 100, vous pouvez toujours avoir 92 233 720 368 547 758 (& 92 000 milliards de lignes) dans votre tableau.

Je pense que l’utilisation du mot "primaire", dans la phrase "primaire" La clé est dans un sens réel, trompeuse.

Tout d'abord, utilisez la définition qu'une "clé". est un attribut ou un ensemble d'attributs qui doivent être uniques dans la table,

Ensuite, avoir une clé sert à plusieurs fins souvent contradictoires.

À utiliser comme conditions de jointure pour un ou plusieurs enregistrements de tables enfant ayant une relation avec cette table parent. (Définition explicite ou implicite d'une clé étrangère dans ces tables enfants)
(lié) Vérification que les enregistrements enfants doivent avoir un enregistrement parent dans l'onglet parent; e (la table enfant FK doit exister en tant que clé dans la table parent)
Pour augmenter le nombre de requêtes devant localiser rapidement un enregistrement / une ligne spécifique dans la table.
Pour assurer la cohérence des données en empêchant l'insertion de lignes en double représentant la même entité logique dans la table. (Ceci est souvent appelé une clé "naturelle" et doit être constituée d'attributs de table (entité) relativement invariants.)

Clairement, toute clé non-significative, non-naturelle (comme un GUID ou un entier généré automatiquement est totalement incapable de satisfaire # 4.

Mais souvent, avec beaucoup (la plupart) tables, une clé totalement naturelle qui peut fournir # 4 sera souvent composée d'attributs multiples et sera trop large, ou si large que son utilisation pour les buts # 1, # 2 ou # 3 entraînera des performances inacceptables.

La réponse est simple. Utilise les deux. Utilisez une clé intégrale auto-génératrice simple pour toutes les jointures et les FK des autres tables enfants, mais assurez-vous que chaque table nécessitant la cohérence des données (très peu de tables en contient) possède une autre clé naturelle unique empêchant l'insertion de lignes de données incohérentes. .. De plus, si vous avez toujours les deux, alors toutes les objections contre l'utilisation d'une clé naturelle (et si cela change? Je dois changer chaque endroit où il est référencé comme un FK) deviennent sans objet, car vous ne l'utilisez pas pour cela. .. Vous ne l’utilisez que dans la table où il s’agit d’une PC, afin d’éviter les doublons incohérents ...

En ce qui concerne les GUID, soyez très prudent lorsque vous les utilisez, car l’utilisation d’indices dans un index peut ralentir la fragmentation de l’index. Les algorithmes les plus couramment utilisés pour les créer placent le paramètre "aléatoire". portion de guid dans les positions de bits les plus significatives ... Cela augmente la nécessité d'une défragmentation / réindexation d'index régulière à mesure que de nouvelles lignes sont ajoutées.

Un peu hors sujet, mais je me sens obligé de me mêler de ...

Si votre clé primaire est un GUID, ne n'en faites pas un index en cluster . Comme les GUID ne sont pas séquentiels, les données seront réorganisées sur le disque pendant presque chaque insertion. (Beurk.) Si vous utilisez des GUID comme clés primaires, ils doivent être des index non clusterisés.

Une chose à ne jamais faire est d'utiliser une clé intelligente. C’est une clé dans laquelle les informations relatives à l’enregistrement sont codées dans la clé elle-même, qui finira par vous piquer.

J'ai travaillé à un endroit où la clé primaire était l'ID du compte, une combinaison de lettres et de chiffres. Je ne me souviens d’aucune précision, mais par exemple, les comptes d’un certain type, allant de 600 à 400, ont commencé par 400. C’était génial, jusqu’à ce que ce client décide de demander les deux types de travail. Ou changé le type de travail qu'ils ont fait.

À un autre endroit, l’emplacement dans l’arbre était utilisé comme clé primaire pour les enregistrements. Il y aurait donc des enregistrements comme celui-ci.

Cat1.subcatA.record1
Cat1.subcatA.record2
Cat1.subcatB.record1
Cat2.subcatA.record1

Bien sûr, la première chose que souhaitaient les clients était un moyen de déplacer des éléments dans l’arbre. L'ensemble des logiciels est mort avant que cela ne se produise.

S'il vous plaît, s'il vous plaît, s'il vous plaît, si vous écrivez un code que je dois entretenir, n'utilisez pas de clé intelligente!

Je suis un partisan de l'incrémentation automatique en tant que clé primaire. Je sais au fond de moi qu’il s’agit d’une échappatoire, mais cela facilite tellement le tri des données lorsqu’elles ont été ajoutées (ORDER BY ID DESC, pour une instance donnée).

3 colonnes semblent terriblement difficiles à analyser humainement.

Et c’est là le compromis: de combien de capacités relationnelles avez-vous besoin, par rapport à la compréhension de This Table Right Here par un humain interrogeant celui-ci (par opposition à la procédure mémorisée ou à l’interface programmatique).

l'incrémentation automatique est pour nous les humains. : - (

En règle générale, cela dépend.

Personnellement, j'aime les incrustations automatiques.

Toutefois, je peux vous dire que vous ne devez jamais vous fier aux données d’autres sources. Je jure que chaque fois que je fais ça, ça revient à me mordre. Eh bien, plus jamais!

Il devrait y avoir au moins 3 colonnes qui composent la clé primaire.

Je ne comprends pas cela.

Parlez-vous d'une "clé naturelle", par exemple "Nom et date de naissance"? Une clé naturelle peut être idéale si elle existe, mais la plupart des candidats à une clé naturelle ne sont pas uniques (plusieurs personnes portent le même nom) ou ne sont pas constants (une personne peut changer de nom).

Int / BigInt qui auto-incrémentent sont suffisamment bons clés primaires.

Je préfère Guid. Un problème potentiel avec l'auto-incrémentation est que la valeur (par exemple, "id de commande") est assignée par l'instance de base de données (par exemple, par la "base de données des ventes") ... qui ne fonctionnera pas entièrement (au lieu de cela, vous aurez besoin de clés composées ) si vous avez besoin de fusionner des données créées par plusieurs instances de base de données (par exemple de plusieurs bureaux de vente disposant chacun de leur propre base de données).

RE GUID

Faites attention à ce qu'il s'agisse d'une très grande base de données VRAIMENT VRAIMENT VRAIMENT , qui demande beaucoup de travail et dont l'accès est rapide.

Lors de mon dernier emploi, où nous avions des bases de données de 100 à 500 millions d'enregistrements, les responsables de notre base de données étaient fortement opposés aux GUID et à un nombre décimal de taille appropriée. Ils ont estimé que (sous Oracle) la différence de taille dans la mémoire interne d'une chaîne Guid - vs - une valeur décimale ferait une différence très notable dans les recherches. (Touches plus grandes = arbres plus profonds à parcourir)

La nature aléatoire des GUID réduit également considérablement le facteur de remplissage des pages d'index, ce qui augmente considérablement les déchirures et les E / S du disque.

Incrémentation automatique des colonnes. Je suis capable de faire fonctionner mon code de manière transparente avec SQL Server ou Oracle, l'un utilisant l'identité, l'autre utilisant des séquences via mon DAL, et je ne pourrais être plus heureux. Je conviens que des GUID sont parfois nécessaires si vous effectuez une réplication ou envoyez des données pour les recevoir ultérieurement lors du traitement par afer.

J'ai toujours utilisé une clé de substitution - un entier auto-incrémenté appelé "id". Je peux voir beaucoup de raisons de le faire même quand une autre option est évidente:

cohérence
Données indépendantes (uniques, non détruites par les modifications de format)
lisible par l'homme

... et aucune raison valable de ne pas:

Ambiguïté dans les jointures? - Les tables de crénelage sont une meilleure pratique, IMHO
Des tables optimales? - Supprimer un octet par entrée est une optimisation prématurée, IMHO
Décision par table? - n'est plus cohérent
Problèmes d'échelle? - hein? Pourquoi?
Structure de données hiérarchique? - C'est dénormalisant, tout un autre sujet de religion. Disons simplement que je suis un partisan dans quelques circonstances théoriques, mais jamais dans la pratique:)

des raisons sensibles contre lesquelles je n’ai pas encore pensé ou que j’ai rencontré sont toujours les bienvenues ...

C’est un classique "ça dépend". Il n'y a pas une seule bonne réponse pour chaque projet. J'aime différentes choses pour différentes situations. Cela dépend si j'utilise un ORM et ce qu'il supporte. Cela dépend de l'architecture globale (distribuée ou non, etc.). Choisissez-en un qui vous conviendra, puis discutez entre les onglets et les espaces.

J'ai tendance à utiliser les options 1 ou 3 en fonction de la taille, du nombre de personnes se connectant et du fait qu'il s'agisse ou non d'une situation de serveur de base de données multiple.

L'option n ° 2 n'a pas beaucoup de sens pour moi. Si l’un des trois n’est pas suffisant pour identifier un enregistrement unique, il est alors possible (sans passer par des manipulations supplémentaires) que deux enregistrements apparaissent avec les mêmes valeurs dans les trois colonnes. Si vous souhaitez imposer l'unicité des combinaisons des trois, ajoutez-leur simplement un index.

Je n'ai utilisé qu'un int automatique ou un GUID. 99% du temps que j'ai utilisé auto-increment int. C’est justement ce que j’ai appris à utiliser lorsque j’ai découvert les bases de données et que je n’ai jamais eu la moindre raison de ne pas les utiliser (bien que je connaisse les raisons pour lesquelles un GUID serait meilleur).

J'aime l'incrémentation automatique car cela facilite la lisibilité. Par exemple, je peux dire "regardez l'enregistrement 129383". et il est assez facile pour quelqu'un d'entrer et de le trouver. Avec un GUID, il est presque impossible à faire.

Après une réponse de définition de base, ce qui constitue une bonne clé primaire est laissé en grande partie à la religion et aux arguments de pause. Si vous avez quelque chose qui est et sera toujours mappé de manière unique sur une ligne individuelle, alors cela fonctionnera comme une clé primaire. Passé ce point, il y a d'autres considérations:

La définition de la clé primaire n'est-elle pas trop complexe? Évite-t-il d’introduire une complexité inutile dans l’intérêt de suivre une "meilleure pratique"?
Existe-t-il une meilleure clé primaire qui nécessiterait moins de temps système pour que la base de données soit gérée (c'est-à-dire INTEGER ou VARCHAR, etc.)?
Suis-je absolument certain que le caractère unique et invariant de la définition de ma clé primaire ne changera pas?

Ce dernier est probablement ce qui amène la plupart des gens à utiliser des éléments tels que des GUID ou des colonnes entières auto-incrémentées, car s’appuyant sur des éléments tels que les adresses, les numéros de téléphone, les prénoms / noms, etc., ne coupez pas cela. Le seul invariant concernant les personnes auxquelles je puisse penser est le SSN, mais je ne suis même pas sûr à 100% de ceux qui resteront à jamais uniques.

Espérons que cela aide à clarifier les choses ...

Pour approcher les clés primaires (et je pense que c'est la meilleure), il faut éviter d'avoir un "défaut". approche. Cela signifie qu'au lieu de simplement taper sur un entier auto-incrémenté et de l'appeler un jour, j'examine le problème et dit "existe-t-il une colonne ou un groupe de colonnes qui seront toujours identiques et ne changeront pas?" Si la réponse est oui, j’adopte cette approche.

Presque toujours des nombres entiers.

Ils ont d’autres bonnes raisons en plus d’être plus petits / plus rapides à traiter. Que préféreriez-vous écrire - " 404040 " ou "3463b5a2-a02b-4fd4-aa0f-1d3c0450026c"?

Seulement un peu pertinent, mais une chose que j’ai commencé à faire récemment lorsque j’ai de petits tableaux de classification (essentiellement ceux qui représenteraient ENUM dans le code) est que je vais faire de la clé primaire un car (3) ou un car (4). ). Ensuite, je fais ces clés primaires représentatives de la valeur de recherche.

Par exemple, j'ai un système de cotation pour nos agents de vente internes. Nous avons " Catégories de coûts " Ainsi, chaque élément de campagne de devis est affecté à l'un des ... J'ai donc une table de correspondance de type appelée "tCostCategories", où la clé primaire est "MTL", "SVC", "TRV", "TAX", "ODC". D'autres colonnes de la table de consultation stockent plus de détails, telles que les significations anglaises normales des codes, "Matériel", "Service", "Voyages", "Taxes", "Autres coûts directs", etc. .

C’est vraiment agréable, car il n’utilise pas plus d’espace qu’un int, et lorsque vous examinez les données source, vous n'avez pas à lier la table de recherche pour savoir quelle est la valeur. Par exemple, une ligne de citation peut ressembler à:

1 PartNumber $ 40 MTL
2 OtherPartNumber $ 29.99 SVC
3 Numéro de pièce2 $ 150 TRV

Il est beaucoup plus simple d'utiliser un int pour représenter les catégories, puis de relier 1, 2, 3 sur toutes les lignes - vous avez les données devant vous et la performance ne semble pas du tout affectée (pas que j'ai vraiment testé.)

En ce qui concerne la vraie question ... j'aime les identifiants uniques RowGUID. Je ne suis pas à 100% à ce sujet, mais toutes les lignes n'ont-elles pas de toute façon le RowGuid interne? Si tel est le cas, utiliser le RowGuid prend en réalité moins de place que le ints (ou autre chose d'ailleurs). Tout ce que je sais, c'est que s'il est suffisant d'utiliser M $ dans GreatPlains, il l'est également pour moi. (Dois-je me baisser ??)

Oh, encore une fois, j’utilise des GUID - j’utilise une structure de données hiérarchique. C'est-à-dire que j'ai une table 'Société' et une table 'Fournisseur' pour lesquelles les clés primaires correspondent. Mais j'ai aussi une table 'Fabricant' qui aussi 'hérite' de Company. Les champs communs aux fournisseurs et aux fabricants n'apparaissent pas dans ces tableaux - ils apparaissent dans Société. Dans cette configuration, utiliser int est beaucoup plus douloureux que Guids. À tout le moins, vous ne pouvez pas utiliser de clé primaire d'identité.

J'aime les clés naturelles, chaque fois que je peux leur faire confiance. Je suis disposé à payer un petit prix de performance pour utiliser des clés qui ont du sens pour les experts en la matière.

Pour les tableaux décrivant des entités, il devrait exister une clé naturelle simple identifiant les instances individuelles de la même manière que les personnes concernées. Si le sujet n'a pas d'identificateur fiable pour l'une des entités, je recourrai à une clé de substitution.

Pour les tables décrivant les relations, j'utilise une clé composée, dans laquelle chaque composant fait référence à une entité qui participe à la relation, et donc à une ligne d'une table d'entités. Encore une fois, l’utilisation d’une clé composée a généralement un impact négatif sur les performances.

Comme d'autres l'ont souligné, le terme "clé primaire". est un peu trompeur. Dans le modèle de données relationnel, le terme utilisé est "clés candidates". Il peut y avoir plusieurs clés candidates pour une seule table. Logiquement, chacun est aussi bon qu'un autre. Choisir l'un d'entre eux comme "primaire" et faire toutes les références via cette touche est simplement un choix que le concepteur peut faire.

Guids.period.

Si vous devez faire évoluer votre système ou si vous devez attribuer la clé primaire par un autre moyen, ce sera votre ami. Vous pouvez ajouter des index pour tout le reste.

mettre à jour pour clarifier ma déclaration.

J'ai travaillé sur de nombreux types de sites. Des petites offres à un seul aux grandes, avec plusieurs serveurs de base de données et serveurs Web. Il y a certainement eu des applications qui auraient très bien fonctionné avec l'incrémentation automatique en tant que clé primaire. Cependant, ceux-ci ne correspondent pas au modèle de la façon dont je fais les choses.

Lorsque vous utilisez un GUID, vous pouvez générer l’identifiant n’importe où. Il peut être généré par un serveur distant, votre application Web, dans la base de données elle-même ou même dans plusieurs bases de données dans une situation de plusieurs maîtres.

D'autre part, une INT incrémentée automatiquement ne peut être générée en toute sécurité que dans la base de données primaire. Encore une fois, cela pourrait convenir si vous avez une application qui sera intimement liée à ce serveur de base de données et que la montée en puissance n'est pas quelque chose qui vous préoccupe.

Bien sûr, l’utilisation des GUID signifie que vous devez avoir des processus de réindexation nocturne. Cependant, si vous utilisez autre chose qu'une INT incrémentée automatiquement, vous devriez le faire de toute façon. Zut, même avec un INT comme primaire, il est probable que vous ayez d'autres index à régénérer pour traiter la fragmentation. Par conséquent, l’utilisation des GUID n’ajoute pas exactement un autre problème, car ces tâches doivent être exécutées indépendamment.

Si vous jetez un coup d'œil aux applications les plus volumineuses, vous remarquerez quelque chose d'important: elles utilisent toutes des GUID codés en Base64. La raison en est simple: l’utilisation des GUID vous permet d’évoluer facilement sur , alors qu’il peut y avoir beaucoup d’obstacles à franchir lorsque vous tentez de réduire l’INTs.

Notre dernière application traverse une période de lourds insertions qui dure environ un mois. Après cela, 90% ou plus des requêtes sont toutes sélectionnées pour le rapport. Pour augmenter la capacité, je peux faire apparaître des serveurs de base de données supplémentaires pendant cette longue période d’insertion; et plus tard facilement les fusionner en une seule base de données pour la génération de rapports. Essayer de le faire avec les INT serait un cauchemar absolu.

Très franchement, chaque fois que vous mettez en cluster une base de données ou configurez une réplication, le serveur de base de données vous demandera de toute façon d'avoir des GUID sur la table. Donc, si vous pensez que votre système doit peut-être évoluer, choisissez celui qui vous convient le mieux.

C’est un sujet complexe, que vous l’ayez compris ou non. Cela pourrait tomber sous la section de cette FAQ StackOverflow.

Quel genre de questions ne devrais-je pas poser ici?

Évitez de poser des questions subjectives, qui argumentent ou qui nécessitent une discussion approfondie. C'est un endroit pour des questions auxquelles on peut répondre!

Cela a été débattu pendant des années et continuera à être débattu pendant des années. Les seuls indices de consensus que j'ai vus sont que les réponses sont assez prévisibles, selon que vous demandez à un gars de OO (les GUID sont la seule solution!), Un modélisateur de données (les clés naturelles sont la seule solution!), ou un DBA orienté performances (les INT sont la seule solution!).

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow