Chapitre 7. Indices et clés

	Auteur
	Écrit par Herouth Maoz

	Note de l'éditeur
	ceci provient de la mailing list, en réponse à la question : "quelle est la différence entre les contraintes PRIMARY KEY et UNIQUE ?".

Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE

        Quelle est la différence entre :

              PRIMARY KEY(fields,...) et
              UNIQUE (fields,...)

       - Est-ce un alias ?
       - si PRIMARY KEY est déja unique, pourquoi existe-t-il une autre clé nommée UNIQUE ?

Une clé primaire est le(s) champ(s) utilisé pour identifier une ligne particulière. Par exemple les numéros de sécurité sociale identifiant une personne.

Une simple combinaison UNIQUE n'a rien à faire avec l'identification de ligne. C'est simplement une contrainte d'intégrité. Par exemple, j'ai une collection de liens. Chaque collection est identifiée par un nombre unique, qui est la clé primaire. Cette clé est utilisée dans les relations.

Cependant, mon application nécessite que chaque collection aura aussi un nom unique. Pourquoi ? Quelqu'un qui voudra modifier cette collection sera capable de l'identifier. Il est plus difficile d'identifier, si vous avez deux collections nommées "Life science", l'une codée 24433 étant celle que vous voulez, l'autre 29882 que vous ne voulez pas.

Ainsi, l'utilisateur sélectionne la collection par son nom. Nous serons donc sûrs que les noms sont uniques dans la base. Cependant, aucune autre table dans la base ne se rattache aux collections table par le nom de la collection. Cela serait très inefficace.

D'autre part, en plus d'être unique, le nom de la collection ne définit pas actuellement la collection. Par exemple, si quelqu'un décide de changer le nom de la collection de "Life science" en "Biologie", ce sera toujours la même collection, avec un nom différent. Tant que le nom est unique, ça fonctionnera.

Ainsi :

• Clé primaire

  • utilisée pour identifier la ligne et ce qui s'y rapporte

  • impossible (ou très dur) à mettre à jour

  • n'admet pas NULL.

• Champs unique

  • utilisé comme une alternative d'accès à la ligne

  • est upgradable, aussi longtemps qu'il est unique.

  • NULL est accepté

Pourquoi les clés non-unique sont définies explicitement dans la syntaxe standard SQL ? Vous devez comprendre que les index sont dépendants de l'implémentation. SQL ne définit pas l'implémentation, mais simplement les relations entre données dans la base. Postgres fournit les index non-unique, mais les index utilisés pour renforcer les clés SQL sont toujours uniques.

Ainsi, vous pouvez interroger une table par diverses combinaisons de ses colonnes, en dépit du fait que vous n'avez pas d'index de ces colonnes. Les index sont simplement une aide implémentée pour chaque SGBDR, de façon à ce que les requêtes soient faites plus efficacement. Certains SGBDR peuvent fournir des mesures supplémentaires, comme garder une clé stockée dans la mémoire principale. Elles auront une commande spéciale, par exemple

CREATE MEMSTORE ON <table> COLUMNS <cols>

(ce n'est pas une commande réelle, juste un exemple).

En fait, quand vous créez une clé primaire ou une combinaison de champs unique, il n'est indiqué nulle part qu'un index est créé, non plus que le rétablissement de données par la clé est plus efficace qu'un scan séquentiel !

Ainsi, si vous voulez utiliser une combinaison de champs qui n'est pas unique comme une clé secondaire, vous n'avez pas réellement a spécifier quoi que ce soit - juste démarrer le rétablissement par cette combinaison ! Cependant, si vous voulez faire un rétablissement efficace, vous aurez a recourir aux moyens que vous procure votre SGBDR - soit un index, ma commande imaginaire MEMSTORE, ou un SGBDR intelligent qui crée des index sans que vpus en ayez connaissance basé sur le fait que vous lui avez envoyé des requêtes fondées sur une combinaison de clés spécifiques.