Si j'ai une table d'une centaine d'utilisateurs, normalement, je voudrais simplement configurer une colonne Userid d'incrément automatique comme clé primaire. Mais si soudainement, nous avons un million d'utilisateurs ou 5 millions d'utilisateurs, alors cela devient vraiment difficile parce que je voudrais commencer à devenir plus distribué auquel cas une clé primaire d'incrémentation automatique serait inutile car chaque nœud créerait les mêmes clés primaires. < / p>
est la solution à cela pour utiliser des clés primaires naturelles? Je suis vraiment difficile de penser à une clé primaire naturelle pour ce groupe d'utilisateurs. Le problème est qu'ils sont tous des jeunes afin qu'ils n'ont ni numéros d'assurance nationaux ni aucun autre identifiant unique que je puisse penser. Je pourrais créer une clé primaire multi-colonnes, mais il reste encore une chance, mais la minuscule des doublons se produisant.
Est-ce que quelqu'un connaît une solution?
merci
9 Réponses :
La solution standard ici est d'utiliser un GUID. Ils ne se produiront pas aussi bien en termes d'indexation, cependant.
Comme vous le savez probablement, vous pouvez sacrifier une partie de l'unicité du GUID en remplaçant la moitié ou un quart du GUID avec une date d'heure. Je crois que cela s'appelle un guide de peigne. La performance de l'indice devient assez proche de celle d'un INT. Cela dit, le GUID consommera plus d'espace dans les pages et causera plus de fractionnement.
Lorsque vous atteignez 5 millions d'utilisateurs, vous n'avez pas besoin de toutes les performances que vous pouvez obtenir? Vous allez déverser la mémoire de mémoire de cache Long Guids sur cette table et de nombreux FKS.
Je dirais que pour le moment, gardez une incrément automatique pour l'ID utilisateur.
Lorsque vous avez cette poussée soudaine de millions d'utilisateurs, vous pouvez penser à la modifier.
En d'autres termes, résolvez le problème lorsque vous l'avez. "L'optimisation prématurée est la racine de tout mal.".
Pour répondre à la question - Certains incréments de l'automobile vous permettront de semer l'incrémentation automatique, de sorte que vous puissiez obtenir différents incréments d'automobile sur les différents nœuds. Cela évitera le problème, tout en permettant d'utiliser un incrément automatique.
Bien que je suis par opposition à une optimisation prématurée / inutile que quiconque, je suis beaucoup plus opposé à la modification des clés primaires sur une table utilisée.
@Adam Robinson - Je suis absolument d'accord. Cependant, il faut aussi être réaliste de certains problèmes à venir.
Je suis d'accord avec Adam. J'aurais peut-être voté si je pensais que Christopher allait avoir un problème avec un domaine d'identité.
Ne jamais utiliser des clés primaires naturelles, sauf si vous voulez de mauvaises performances et du potentiel de mauvaises données. Il y a très peu de clés naturelles qui sont soumises à changer dans le temps, notamment les noms. Si une clé naturelle change, tous les enregistrements d'enfants associés doivent également changer. C'est clairement mauvais.
Vous pouvez utiliser GUIDS. Mais 5 millions n'en sont rien en termes de données et ne nécessiteraient probablement pas de changement. Nous avons plus de 10 000 000 personnes différentes de notre système et nous n'avons qu'une base de données de taille moyenne sans partition ou besoin de GUID.
Un GUID est un moyen facile de sortir mais ...
Comment Distribué a-t-il besoin d'être? S'il s'agit d'un nombre limité de bases de données, vous pouvez donner à chaque base de données une gamme de numéros à utiliser. Ainsi, par exemple, la première base de données automatique génère des nombres compris entre 0 et 999 9999 et la suivante utilise 1 000 000 à 1 999 99999999. De cette façon, ils peuvent chacun générer un identifiant d'utilisateur sans se heurter mutuellement. Si la base de données inclut un numéro unique en identifiant, les gammes peuvent être générées automatiquement à partir de ce numéro.
Je ne pense pas que vous puissiez utiliser une colonne d'incrémentation automatique pour le faire, mais une procédure stockée pourrait générer des nombres de cette manière.
Les GUID sont bons, mais sont soumis à une collision (bien que rare).
Ceci pourrait être une solution non standard, mais je vais le jeter là-bas:
Vous pouvez utiliser des numéros d'incrémentation automatique, mais vous séparer le chiffre d'espace en fonction de la distribution à l'avenir.
Alors disons que vous avez 3 serveurs. Enregistrez les identifiants comme suit:
serveur 1: 0 - 9,999,999
Serveur 2: 10 000 000 - 19 999 999 de
Serveur 3: 20 000 000 - 29 999 999
Même dans les contraintes d'un Int 32 bits, cela devrait laisser beaucoup d'espace d'expansion (pourrait même utiliser des lacunes de 100 000 000 si vous êtes inquiet), et il garantit essentiellement l'unicité de l'ensemble du système.
Les GUID sont des ordures comme des clés lorsqu'elles sont regroupées. Si non regroupé, vous aurez toujours besoin d'un index en cluster sur une autre colonne.
Utilisez une clé entière et pour chaque Si vous avez des nœuds / sites, une deuxième colonne avec SiteID fonctionnera également. nouveau nœud / site
Bien sûr, le Downvoter sait que les Guids sont supérieurs ...?
Si vous avez besoin de millions d'identifiants et que de nombreux nœuds, créez la clé primaire un composite de: ce qui est bien meilleur qu'un GUID (plus petit, utilise moins de mémoire et sera plus rapide)
Si vous utilisez MSSQL, vous pouvez créer le PK de votre table comme stratégiqueIdentifier et définir la valeur par défaut ou la liaison à NewID ().
Je vous suggère de ne jamais considérer les GUDRS Une seule raison est que je rencontre actuellement des problèmes supposons que si vous avez des millions d'utilisateurs, vous aurez peut-être besoin d'un plus grand degré de concurrence et de GUIDS ruinera votre vie en insérant et en supprimant parce que vous allez avoir un index sur eux et en défaut, il s'agira d'un indice en cluster qui signifie que lorsque vous avez un index en cluster, chaque insert et Supprimer déplaceront l'enregistrement physiquement et que de plus, les GUID ne sont pas séquentiels, il n'ya pas de chance de zéro que chaque nouvel insert vienne en bas ou en haut sur la page. Donc, l'opération d'insertion générale et de suppression deviendra très coûteuse et si vous supprimez l'index, vos sélections deviendront coûteuses.
Spécialement si vous avez plusieurs tables et que des relations entre elles ne considèrent pas les GUID comme clé primaire.
Il y a la suite de deux solutions que je recommanderais.
Si vous pouvez créer des touches composites qui seront parfaites comme si son logiciel bancaire pourrait être branchiide, transactionneur deviendra la clé primaire où branchior est l'identité du nœud insérant l'enregistrement et le transacidid est un numéro automatique à branche afin que vous obtiendrez un caractère unicité tout le chemin.
Si ci-dessus n'est pas ce que vous aimez faire ou que vous envisagez, vous pouvez utiliser le GUID comme un fichier unique classé, mais ajoutez un numéro d'incrément automatique en tant que clé primaire, cela vous aidera à réduire le coût global que le client (noeud ) Envoie des données à l'aide de (Web Service) RPC, alors vous devez insérer un enregistrement dans la base de données du serveur, puis un nombre automatique sera généré et que ce nombre peut être utilisé pour une sélection ultérieure, une suppression ou une mise à jour future, mais le client n'a pas à connaître ce nombre
Je comprends que la deuxième solution est un peu déroutante et complexe mais elle est encore meilleure que d'utiliser des GUIDS comme PK. Mais si la solution 1 est applicable, allez-y.
Lorsque je dis que je ne dis que ce n'est pas seulement le temps de traitement, mais également son temps de serrure (attente), c'est-à-dire totalement le gaspillage d'argent et que votre serveur quadrial est peut-être effectué la moitié et plus de serrures signifient plus de chance d'embûches afin Mon ami n'utilise jamais de Guids.
Cordialement Mubashare