Clé primaire ou index unique?

Au travail, nous avons une grande base de données avec des index uniques au lieu de clés primaires et tout fonctionne bien.

Je conçois une nouvelle base de données pour un nouveau projet et j'ai un dilemme:

Dans la théorie DB, la clé primaire est un élément fondamental, c'est OK, mais dans les projets REAL, quels sont les avantages et les inconvénients des deux?

Qu'utilisez-vous dans les projets?

EDIT: ... et qu'en est-il des clés primaires et de la réplication sur le serveur MS SQL?

Qu'est-ce qu'un index unique?

Un index unique sur une colonne est un index sur cette colonne qui applique également la contrainte selon laquelle vous ne pouvez pas avoir deux valeurs égales dans cette colonne sur deux lignes différentes. Exemple:

CREATE TABLE table1 (foo int, bar int);
CREATE UNIQUE INDEX ux_table1_foo ON table1 (toto); - Créez un index unique sur foo.

INSERT INTO table1 (foo, bar) VALUES (1, 2); -- D'ACCORD
INSERT INTO table1 (foo, bar) VALUES (2, 2); -- D'ACCORD
INSERT INTO table1 (foo, bar) VALUES (3, 1); -- D'ACCORD
INSERT INTO table1 (foo, bar) VALUES (1, 4); -- Échoue!

Entrée en double '1' pour la clé 'ux_table1_foo'

La dernière insertion échoue car elle enfreint l'index unique sur la colonne foolorsqu'il essaie d'insérer la valeur 1 dans cette colonne une deuxième fois.

Dans MySQL, une contrainte unique autorise plusieurs NULL.

Il est possible de créer un index unique sur plusieurs colonnes.

Clé primaire contre index unique

Les choses qui sont les mêmes:

• Une clé primaire implique un index unique.

Des choses différentes:

• Une clé primaire implique également NOT NULL, mais un index unique peut être nullable.
• Il ne peut y avoir qu'une seule clé primaire, mais il peut y avoir plusieurs index uniques.
• S'il n'y a pas d'index cluster défini, la clé primaire sera l'index cluster.

Vous pouvez le voir comme ceci:

Une clé primaire est unique

Une valeur unique ne doit pas nécessairement être la représentaion de l'élément

Sens?; Eh bien, une clé primaire est utilisée pour identifier l'élément, si vous avez une «personne», vous aimeriez avoir un numéro d'identification personnel (SSN ou autre) qui est principal pour votre personne.

D'un autre côté, la personne peut avoir un e-mail qui est unique, mais qui ne l'identifie pas.

J'ai toujours des clés primaires, même dans les tables de relations (la table du milieu / table de connexion), je pourrais les avoir. Pourquoi? Eh bien, j'aime suivre une norme lors du codage, si la "Personne" a un identifiant, la Voiture a un identifiant, eh bien, alors la Personne -> Voiture devrait avoir un identifiant aussi!

Les clés étrangères fonctionnent avec des contraintes uniques ainsi que des clés primaires. À partir de Books Online:

Une contrainte FOREIGN KEY ne doit pas être liée uniquement à une contrainte PRIMARY KEY dans une autre table; il peut également être défini pour référencer les colonnes d'une contrainte UNIQUE dans une autre table

Pour la réplication transactionnelle, vous avez besoin de la clé primaire. À partir de Books Online:

Les tables publiées pour la réplication transactionnelle doivent avoir une clé primaire. Si une table se trouve dans une publication de réplication transactionnelle, vous ne pouvez désactiver aucun index associé à des colonnes de clé primaire. Ces index sont requis par la réplication. Pour désactiver un index, vous devez d'abord supprimer la table de la publication.

Les deux réponses concernent SQL Server 2005.

Le choix du moment d'utilisation d'une clé primaire de substitution par opposition à une clé naturelle est délicat. Des réponses telles que, toujours ou jamais, sont rarement utiles. Je trouve que cela dépend de la situation.

A titre d'exemple, j'ai les tableaux suivants:

CREATE TABLE toll_booths (
    id            INTEGER       NOT NULL PRIMARY KEY,
    name          VARCHAR(255)  NOT NULL,
    ...
    UNIQUE(name)
)

CREATE TABLE cars (
    vin           VARCHAR(17)   NOT NULL PRIMARY KEY,
    license_plate VARCHAR(10)   NOT NULL,
    ...
    UNIQUE(license_plate)
)

CREATE TABLE drive_through (
    id            INTEGER       NOT NULL PRIMARY KEY,
    toll_booth_id INTEGER       NOT NULL REFERENCES toll_booths(id),
    vin           VARCHAR(17)   NOT NULL REFERENCES cars(vin),
    at            TIMESTAMP     DEFAULT CURRENT_TIMESTAMP NOT NULL,
    amount        NUMERIC(10,4) NOT NULL,
    ...
    UNIQUE(toll_booth_id, vin)
)

Nous avons deux tables d'entité ( toll_boothset cars) et une table de transaction ( drive_through). La toll_boothtable utilise une clé de substitution car elle n'a aucun attribut naturel dont la modification n'est pas garantie (le nom peut facilement être changé). La carstable utilise une clé primaire naturelle car elle possède un identifiant unique non modifiable ( vin). ledrive_through table de transaction utilise une clé de substitution pour une identification facile, mais a également une contrainte unique sur les attributs qui sont garantis uniques au moment où l'enregistrement est inséré.

http://database-programmer.blogspot.com a quelques bons articles sur ce sujet particulier.

Il n'y a pas d'inconvénients des clés primaires.

Pour ajouter juste quelques informations aux réponses @MrWiggles et @Peter Parker, lorsque la table n'a pas de clé primaire, par exemple, vous ne pourrez pas modifier les données dans certaines applications (elles finiront par dire qc comme ne peut pas modifier / supprimer des données sans clé primaire). Postgresql permet à plusieurs valeurs NULL d'être dans la colonne UNIQUE, PRIMARY KEY n'autorise pas les NULL. Certains ORM qui génèrent du code peuvent également rencontrer des problèmes avec les tables sans clés primaires.

METTRE À JOUR:

Autant que je sache, il n'est pas possible de répliquer des tables sans clés primaires dans MSSQL, du moins sans problèmes ( détails ).

Si quelque chose est une clé primaire, selon votre moteur de base de données, la table entière est triée par clé primaire. Cela signifie que les recherches sont beaucoup plus rapides sur la clé primaire car elle n'a pas à faire de déréférencement comme cela a à voir avec tout autre type d'index. En plus de cela, ce n'est que de la théorie.

En plus de ce que les autres réponses ont dit, certaines bases de données et certains systèmes peuvent nécessiter la présence d' un primaire. Une situation me vient à l'esprit; lors de l'utilisation de la réplication d'entreprise avec Informix, un PK doit être présent pour qu'une table participe à la réplication.

Tant que vous n'autorisez pas NULL pour une valeur, elles doivent être gérées de la même manière, mais la valeur NULL est gérée différemment sur les bases de données (AFAIK MS-SQL n'autorise pas plus d'une (1) valeur NULL, mySQL et Oracle le permettent , si une colonne est UNIQUE) Vous devez donc définir cette colonne NOT NULL UNIQUE INDEX

Il n'y a pas de clé primaire dans la théorie des données relationnelles, il faut donc répondre à votre question sur le plan pratique.

Les index uniques ne font pas partie de la norme SQL. L'implémentation particulière d'un SGBD déterminera quelles sont les conséquences de la déclaration d'un index unique.

Dans Oracle, la déclaration d'une clé primaire entraînera la création d'un index unique en votre nom, la question est donc presque sans objet. Je ne peux pas vous parler des autres produits SGBD.

Je suis favorable à la déclaration d'une clé primaire. Cela a pour effet d'interdire les valeurs NULL dans la (les) colonne (s) clé ainsi que d'interdire les doublons. Je suis également favorable à la déclaration de contraintes REFERENCES pour appliquer l'intégrité de l'entité. Dans de nombreux cas, déclarer un index sur le (s) coulmn (s) d'une clé étrangère accélérera les jointures. Ce type d'index ne doit en général pas être unique.

Les INDEXES CLUSTERES présentent certains inconvénients par rapport aux INDICES UNIQUES.

Comme déjà indiqué, un INDEX CLUSTERED classe physiquement les données dans la table.

Cela signifie que lorsque vous en avez beaucoup en cas d'insertion ou de suppression sur une table contenant un index clusterisé, à chaque fois (enfin, presque, en fonction de votre facteur de remplissage) vous modifiez les données, la table physique doit être mise à jour pour rester triée.

Dans des tables relativement petites, cela convient, mais lorsque vous accédez à des tables contenant des données en Go et que les insertions / suppressions affectent le tri, vous rencontrerez des problèmes.

Je ne crée presque jamais de table sans clé primaire numérique. S'il y a aussi une clé naturelle qui doit être unique, je mets également un index unique dessus. Les jointures sont plus rapides sur les entiers que sur les clés naturelles multicolonnes, les données ne doivent changer qu'à un seul endroit (les clés naturelles ont tendance à avoir besoin d'être mises à jour, ce qui est une mauvaise chose lorsqu'elles sont dans les relations clé primaire - clé étrangère). Si vous avez besoin d'une réplication, utilisez un GUID au lieu d'un entier, mais pour la plupart, je préfère une clé lisible par l'utilisateur, surtout s'il a besoin de la voir pour faire la distinction entre John Smith et John Smith.

Les rares fois où je ne crée pas de clé de substitution, c'est lorsque j'ai une table de jointure qui est impliquée dans une relation plusieurs-à-plusieurs. Dans ce cas, je déclare les deux champs comme clé primaire.

Je crois comprendre qu'une clé primaire et un index unique avec une contrainte non nulle sont identiques (*); et je suppose que l'un choisit l'un ou l'autre en fonction de ce que la spécification indique ou implique explicitement (une question de ce que vous voulez exprimer et appliquer explicitement). S'il nécessite un caractère unique et non nul, alors faites-en une clé primaire. S'il arrive que toutes les parties d'un index unique ne soient pas nulles sans aucune exigence, alors faites-en simplement un index unique.

La seule différence restante est que vous pouvez avoir plusieurs index uniques non nuls, alors que vous ne pouvez pas avoir plusieurs clés primaires.

(*) Sauf une différence pratique: une clé primaire peut être la clé unique par défaut pour certaines opérations, comme la définition d'une clé étrangère. Ex. si l'on définit une clé étrangère référençant une table et ne fournit pas le nom de la colonne, si la table référencée a une clé primaire, alors la clé primaire sera la colonne référencée. Sinon, la colonne référencée devra être nommée explicitement.

D'autres ici ont mentionné la réplication de base de données, mais je n'en sais rien.

L'index unique peut avoir une valeur NULL. Il crée un INDEX NON CLUSTERED. La clé primaire ne peut pas contenir de valeur NULL. Il crée un INDEX CLUSTERED.

Dans MSSQL, les clés primaires doivent augmenter de manière monotone pour de meilleures performances sur l'index clusterisé. Par conséquent, un entier avec insertion d'identité est meilleur que toute clé naturelle qui pourrait ne pas augmenter de manière monotone.

Si ça m 'allait...

Vous devez satisfaire les exigences de la base de données et de vos applications.

L'ajout d'un entier à incrémentation automatique ou d'une colonne d'identifiant long à chaque table pour servir de clé primaire prend en charge les exigences de la base de données.

Vous ajouteriez ensuite au moins un autre index unique à la table à utiliser par votre application. Ce serait l'index sur employee_id, ou account_id, ou customer_id, etc. Si possible, cet index ne doit pas être un index composite.

Je préférerais les indices sur plusieurs domaines individuellement aux indices composites. La base de données utilisera les index de champ unique chaque fois que la clause where inclut ces champs, mais elle n'utilisera un composite que lorsque vous fournissez les champs exactement dans le bon ordre - ce qui signifie qu'elle ne peut pas utiliser le deuxième champ dans un index composite à moins que vous ne fournissiez le premier et le second de votre clause where.

Je suis tout à fait favorable à l'utilisation d'indices de type calculé ou de fonction - et je recommanderais de les utiliser sur des indices composites. Il est très facile d'utiliser l'index de fonction en utilisant la même fonction dans votre clause where.

Cela prend en charge les exigences de votre application.

Il est fort probable que d'autres index non primaires soient en fait des mappages de cette valeur de clé d'index vers une valeur de clé primaire, pas celle de rowid (). Cela permet des opérations de tri physiques et des suppressions sans avoir à recréer ces index.