Meilleure alternative aux clés primaires de numérotation automatique

Je cherche une meilleure clé primaire que le type de données autonumber, à savoir parce qu'elle est limitée à un entier long, quand j'ai vraiment besoin du champ pour refléter un nombre ou une chaîne de texte ne répétera jamais, peu importe combien d'enregistrements sont ajoutés ou supprimés de la table. Le problème est que je ne suis pas sûr de savoir comment implémenter quelque chose comme transformer la date et l'heure en une chaîne hexadécimale et l'utiliser comme un champ unique que je peux utiliser comme clé primaire. Suis-je trop paranoïaque pour manquer d'espace?Meilleure alternative aux clés primaires de numérotation automatique

- EDITED 16/03/2010 @ 1237 heures -

J'ai eu une personne qui, à l'époque, je pensais était une référence merveilleuse pour les questions liées à l'accès me disent que les ID de réplication sont juste un compteur pour le nombre de fois qu'un article a été répliqué ... donc je ne l'ai jamais exploré plus loin. Après le nombre de réponses, j'ai up-modded, et accepté une réponse. Je suppose que j'avais juste un débutant stupide Accesss moment de développeur. Sérieusement, merci encore pour tous ceux qui ont répondu!

Source

2010-03-15 Comrad_Durandal

Un champ de numérotation automatique est long, 4 octets et peut contenir 2 147 483 647 enregistrements.Ensuite, il ya les nombres négatifs qui seraient un autre -2 147 483 648 enregistrements Si vous êtes préoccupé par le manque d'espace, je recommanderais storiung vos données dans un système de données autre que le format Access aka Jet. –

Il n'est pas clair si vous programmez votre application dans Access ou non. Si oui, alors vous venez d'ajouter des problèmes à votre processus de développement, comme indiqué dans l'article Michael Kaplan cité par Tony Toews dans les commentaires downthread. Vous pouvez en être content, mais je pense surtout que les personnes qui pensent avoir besoin de GUID dans une application Access sans avoir de dépendance externe qui forcent le problème se trompent souvent et introduisent des problèmes de développement inutiles. Mais notez que j'ai dit "la plupart du temps" et pas "toujours". –

GUID. Ils sont assez unique

http://en.wikipedia.org/wiki/Globally_Unique_Identifier

Vous n'avez pas mentionné votre langage de programmation. C# serait quelque chose comme

String myKey = Guid.NewGuid().toString();

Source

2010-03-15 05:24:29 Kieran

Lisez l'article suivant avant de prendre en compte les GUID. Objet: INFO: réplication et GUID, le bon, le mauvais et le vilain http://www.trigeminal.com/usenet/usenet011.asp?1033 –

si vous définissez la base de données pour avoir une valeur de texte et mettez votre GUID manuellement cela résoudrait tous les problèmes énumérés sur votre lien. Et pour le point 4. Personne ne veut être un nombre autant que le ne veut pas être un groupe aléatoire de lettres. Si je faisais un système, il serait capable de trouver un enregistrement sans l'utilisation d'une clé primaire – Kieran

Le passage au type de texte va modifier l'indexation, et il est probablement moins efficace (les lettres dans un GUID ne sont pas du texte, mais Numéros hexadécimaux). Mais je ne sais pas avec certitude - je n'ai jamais vu une raison d'utiliser un GUID comme un PK (bien que toutes mes bases de données répliquées les utilisent pour les fonctions de réplication, quelque chose que je laisse entièrement au moteur de base de données). –

Pourquoi pensez-vous manquer d'espace? Peut-être que vous ne réalisez pas la taille d'un entier 64 bits, exactement. Cela permet d'environ 10 milliards de milliards d'enregistrements. Si vous avez créé 100 enregistrements par seconde, il faudra plus de five billion years pour manquer d'entiers.

Source

2010-03-15 05:13:40

Un type Access 'Long' est seulement de 32 bits. – Gabe

OOH !!!! Seulement 32 bits! Si Jet/ACE est approprié comme magasin de données pour l'application, l'entier long Jet/ACE sera suffisant. Si la première condition n'est pas remplie, le problème n'est pas le choix de Autonumber comme PK. –

Techniquement, Microsoft Access utilise seulement 4 octets pour stocker un entier long, d'où la question d'origine - mais j'ai obtenu une réponse qui fonctionne. Je vous remercie. –

réponse Per John, vous avez peu de chances de manquer d'entiers longs. Mais si vous préférez une chaîne unique, la solution la plus simple est un UUID. Il ne prend pas d'entrées, mais les chances de générer deux UUID identiques sont négligeables.

Par exemple, en Python:

import uuid 
uuid.uuid4()

Il y a des fonctions UUID disponibles dans la plupart toutes les langues: http://en.wikipedia.org/wiki/Uuid

Source

2010-03-15 05:30:00 Tom

Dans quelle circonstance dans laquelle Jet/ACE est un magasin de données approprié, ne seriez-vous jamais à court d'entiers longs? –

Pourquoi êtes-vous limité à un entier long? Lorsque vous spécifiez un champ NuméroAuto, vous pouvez lui indiquer d'utiliser un Replication ID au lieu de Long Integer et il s'agira d'une valeur unique de 128 bits appelée GUID.

Bien que vous puissiez utiliser la date et l'heure comme clé primaire, voici pourquoi pas:

La date et l'heure ne sont pas aussi unique que vous pourriez penser. Si vous faites des enregistrements très rapidement, vous pourriez vous retrouver avec deux étant insérés entre les ticks de l'horloge, entraînant les deux à se retrouver avec le même temps. Ou l'horloge de votre ordinateur pourrait simplement être réinitialisée à l'envers. Ou l'heure d'été peut prendre fin et si vous stockez les heures locales, vous vous retrouverez avec des temps en double.

Source

2010-03-15 05:31:16 Gabe

Je ne conseillerais pas d'utiliser le tampon DateTime comme clé primaire. – Kieran

En effet, Kieran, le gros de mon article expliquait pourquoi ce n'était pas une bonne idée. – Gabe

+1 après modification. L'ID de réplication est spécifique à la base de données et supprime le besoin de le mettre dans le code. Mieux que ma solution. – Kieran

Une solution très simple consiste à utiliser un Autonumber avec l'option "Random" au lieu de "Increment". J'ai lu quelque part que puisque les nombres ne sont pas contigus, il a l'avantage supplémentaire d'améliorer la simultanéité en ajoutant de nouveaux enregistrements de plusieurs clients simultanément.

Source

2010-12-29 21:28:41

En fait, lors de l'ajout d'enregistrements, cela n'améliore pas la concurrence, car de nouveaux enregistrements (et les valeurs d'index correspondantes) vont être stockés dans de nouvelles pages de données. Mais pour éditer les données existantes dans un fichier compacté, il devrait, théoriquement, répartir les données uniformément sur toutes les pages de données, ce qui pourrait améliorer la simultanéité. Mais c'est seulement après un compact que vous obtiendrez des résultats parfaits de cela, et cela s'applique uniquement à l'édition des enregistrements existants, pas à des ajouts d'enregistrements. –

@David, Merci pour l'explication. Maintenant, je pense que je me souviens avoir vu cette information dans un de vos messages sur SO. Intéressant ... et souvenu ;-) –

Meilleure alternative aux clés primaires de numérotation automatique

Répondre

Questions connexes