Ce type de données est recommandée pour les ID?

Je me rends compte que cette question est très probablement été demandé avant, mais j'ai cherché un peu, entre les questions sur StackOverflow, et je n'ai pas vraiment trouver de réponse à la mienne, donc voilà. Si vous trouvez une copie, veuillez communiquer le lien.

Pour une raison que je préfère utiliser Guids (uniqueidentifier dans MsSql) pour mon champs de clé primaire, mais je ne sais vraiment pas pourquoi ce serait mieux. Dans beaucoup de tutoriels que j'ai parcouru moi-même à travers dernièrement une incrémenté automatiquement int a été utilisé. Je peux voir les avantages et les inconvénients avec les deux:

  • Un Guid est toujours de la même taille et de même longueur, et il n'y a pas de raison de s'inquiéter de manquer d'entre eux, alors qu'il y a une limite au nombre d'enregistrements que vous pourriez avoir avant de vous exécuter de chiffres qui s'inscrivent dans une int.
  • int est (au moins en C#) type nullable, qui s'ouvre pour un couple de raccourcis lors de l'interrogation des données.
  • Et int est plus facile à lire.
  • Je parie que vous pourriez venir avec au moins un couple de plus de choses ici.

Donc, aussi simple que le titre dit: Ce qui est recommandé type de données pour l'IDENTIFIANT (clé primaire) de colonnes dans une base de données?

EDIT: Après avoir reçu un couple de réponse courte, je dois également ajouter cette question de suivi. Sans elle, votre réponse n'est ni convaincant ni éduquer... 😉 Pourquoi pensez-vous donc, et quels sont les inconvénients de l'autre option qui vous pas choisir qui à la place?

il convient de rappeler que le GUID et un entier sont que des façons différentes de l'affichage et de générer une séquence d'octets. Où les services de renseignements sont générés de manière séquentielle, les Guid sont générés de façon "aléatoire" et il y a plus d'octets. cela signifie que vous n'avez pas besoin de voir l'état actuel de la base de données pour générer un. tout peut accepter les valeurs null en C# avec une ? sur elle.

OriginalL'auteur Tomas Aschan | 2009-05-31

  1. 8

    Tout type entier de taille suffisante pour stocker des données anticipées plages. Généralement 32 bits entiers sont considérés comme trop petits (à juste titre ou à tort) pour les tables avec beaucoup de lignes ou de modifications. Une version 64 bits de type int, c'est beaucoup. De nombreuses bases de données de ne pas avoir ou de ne pas utiliser ce type entier, mais l'utilisation d'un NUMÉRO de type spécifié échelle et de précision. 10-15 chiffres est assez commun de taille.

    La raison du choix de types d'entiers est double:

    1. Taille; et
    2. Vitesse.

    La taille d'un entier est:

    • 32 bits: 4 octets;
    • 64 bits: 8 octets;
    • Décimale codée binaire: deux chiffres par octet ainsi que d'un octet pour signer, à l'échelle et/ou de précision.

    De la comparer à une GUID, qui est de 128 bits ou avoir un cours normal de la chaîne, qui est au moins un octet par caractère (plus dans certains encodages de caractères), plus une surcharge qui pourrait être aussi peu que un seul octet (valeur null) ou pourrait être beaucoup plus dans certains cas.

    Tri des entiers est trivial et, en supposant qu'ils sont uniques et la gamme est suffisamment faible, peut-être fait en O(n) fois, par rapport à, au mieux, O(n log n).

    aussi, tout aussi important, la plupart des bases de données peut générer des Identifiants uniques par le biais de l'auto-incrémentation des colonnes et/ou des séquences. Garantir l'unicité d'une demande n'est en fait assez difficile et tend à ballonnement clés.

    Plus auto-généré entier clés sont généralement soit lâche ou absolument commandé (en fonction de la base de données et de configuration), ce qui est une qualité utile. Généré de façon aléatoire, les Guid sont fondamentalement non ordonnée, ce qui est beaucoup moins utile.

    Merci pour votre réponse! Voir mon montage pour une question de suivi.

    OriginalL'auteur cletus

  2. 6

    Populaire bases de données de permettre un plus grand champs autoincrement depuis des années maintenant, donc il est beaucoup moins un problème.

    Que pour quoi l'utiliser, c'est toujours un choix. On n'est pas clairement mieux que les autres, ils ont des caractéristiques différentes et chacun est bon dans différents scénarios. J'ai utilisé à la fois dans le temps, et le prochain schéma, je travaille avec, je vais examiner les deux.

    Pros pour GUID:

    • Doit être unique sur les ordinateurs.
    • Aléatoire, immémoriaux goo signifie que les personnes sont susceptibles d'utiliser cette seulement pour son usage prévu d'un identifiant opaque.

    Avantages pour l'auto-incrémentation:

    • De l'homme compréhensible.
    • Séquentielle attribution signifie que vous pouvez utiliser un index cluster et l'impact sur les performances.
    • Adapté pour le partitionnement des données.

    OriginalL'auteur dwc

  3. 5

    Un gros inconvénient de l'utilisation de clés GUID est qu'il est difficile de réaliser des "ad-hoc" des requêtes à la main. Parfois, il est très utile que vous pouvez faire ceci:

    SELECT * from Utilisateur UserID=452245

    Avec GUID touches de cela peut devenir très ennuyeux.

    Je recommanderais les entiers 64 bits

    Je voudrais ajouter que les Guid sont pas facilement lisibles par l'homme, donc, si j'ai appeler le support client avec mon ID de Transaction, je préfère donner un numéro que d'un GUID. Seules les machines devraient lire GUID.

    OriginalL'auteur Philippe Leybaert

  4. 2

    Me dire quels sont les critères que vous jugez important.

    Ce qui est nécessaire est d'être unique dans la table.

    Un GUID est un mondial de manière probabiliste-l'identificateur unique. Il est également grand. Si vous avez besoin de vos indices pour être uniques à l'intérieur d'epsilon sur toute autre base de données de l'installation dans l'univers, c'est un bon choix. Sinon, c'est à l'aide de beaucoup d'espace inutilement.

    Une incrémentation automatique du numéro est bon; il est petit, et assurez-vous d'être unique dans la table. Sur l'autre main, il ne vous donne aucune protection contre la duplication; deux entrées identiques, sauf pour le nombre magique, sont faciles à créer.

    À l'aide de la valeur qui est liée à l'entité décrit évite, mais vous avez le problème de l'unicité.

    OriginalL'auteur Charlie Martin

  5. 1

    Si vous utilisez une longue, vous pouvez créer plus de 1000 une seconde et pas de clés primaires pour 29 millions d'années.

    D'autres l'ont déjà mentionné quelques-uns des avantages de l'utilisation d'un type entier au lieu d'un UUID/GUID. L'un des plus grands avantages est la vitesse et la compacité de l'index.

    Une application j'ai été récemment impliqué dans la où j'ai fait la conception de base de données, j'ai besoin d'Uuid, mais ne veulent pas renoncer aux avantages de l'utilisation de la nostalgie pour les clés primaires, donc j'ai eu un "allIds" table mappée chaque clé primaire dans le système à un UUID. Tous mes clés primaires ont été générés à partir d'une seule séquence, de sorte qu'ils étaient tous uniques sur toutes les tables.

    Merci pour votre réponse! Voir mon montage pour une question de suivi.

    OriginalL'auteur Paul Tomblin

  6. 0

    Si la base de données est distribuée, où vous pourriez obtenir des enregistrements à partir d'autres bases de données, la clé primaire doit être unique au sein d'une table à travers toutes les bases de données. GUID résout ce problème, mais au coût de l'espace. Une combinaison de l'auto-incrémentation et de l'espace de noms serait un bon compromis.

    Ce serait bien si les bases de données pourrait fournir inbuild soutien pour autoincrements avec des "préfixes". Ainsi, dans une base de données, j'obtiens IDs, comme X1,X2,X3 ... et ainsi de suite alors que dans l'autre base de données, il pourrait être Y1,Y2,Y3, ... et ainsi de suite.

    Et ce type de données ne vous supposez que vos X1 et Y2 sera? Les chaînes? Dans ce cas, vous êtes mieux de l'utilisation d'un GUID...

    OriginalL'auteur Sathya

  7. 0

    J'ai posé une question similaire qui a quelques réponses qui pourraient vous aider. La réplication semble être le plus grand avantage de l'utilisation de Guid.

    Raisons de ne pas utiliser un numéro d'incrémentation automatique pour une clé primaire

    OriginalL'auteur Nick

  8. 0

    Suivre Cletus les conseils,
    avec l'inconvénient supplémentaire d'elle dépend en grande partie sur ce que votre storting. Ne jamais utiliser un GUID. GUID d'un ensemble d'inconvénients, et seulement un ou deux avantages.

    OriginalL'auteur scope_creep