Discussion :

[ylarvor]

Sql Pro écrit "
La contrainte d'unicité exige que toutes les valeurs explicites contenues dans la colonne soient uniques au sein de la table. En revanche, la colonne peut ne pas être renseignée. En effet, souvenez vous que les marqueurs NULL se propagent dans les calculs et donc comparaison d'un marqueur NULL à un ensemble de valeurs est impossible et se solde par le renvoi d'un marqueur UNKNOW à la place des valeurs TRUE ou FALSE attendue.
"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
CREATE TABLE T_PERSONNE7
(PRS_NOM            VARCHAR(32),
 PRS_PRENOM         VARCHAR(32),
 PRS_TELEPHONE      CHAR(14)     UNIQUE)

Dans cette discussion

http://www.developpez.net/forums/sho...d.php?t=462214

fsmrel écrit :

Je dirais même plus : ça n’a strictement rien à voir. La clé primaire est un concept du niveau relationnel, logique. L’index, qu’il soit "primaire", "unique", cluster", est du niveau physique, rayon épicerie. J'en veux pour preuve que ce concept ne fait pas partie du Modèle Relationnel de Données.

Pour mémoire, jusqu'en 1988, DB2 ne nous permettait pas de déclarer des clés primaires et étrangères. Concernant les premières, nous garantissions l’unicité par le truchement des index de type UNIQUE. Pour les secondes, on faisait comme on pouvait, c'est-à-dire par programme.

En juillet 1988, j’ai disposé de la version 2 de DB2, et enfin, avec l’instruction CREATE TABLE j’ai pu coder les clauses PRIMARY KEY et FOREIGN KEY, ce que nous attendions tous évidemment avec impatience. Mais j’ai pu constater qu’IBM ne s’embarrassait pas, en nous imposant un diktat injustifié consistant en la création obligatoire d’un index de type UNIQUE pour chaque clé primaire (la seule justification que je vois : "ça nous fera toujours du développement en moins"). J’estime que la décision de créer un index est du ressort de l’utilisateur et de lui seul (en l'occurrence le DBA). Si j’ai des tables qui occupent plus de 3 pages de données, je créerai un index. Pour la foultitude des petites tables de référence (du genre Pays, Départements, Catégorie juridique, code APE, titre de civilité, type de ceci, type de cela) qui tiennent en une page, il eut été préférable qu’IBM mît à notre disposition une routine ad-hoc, nous aurions fait l’économie d’une diarrhée de fichiers. En l’occurrence l’intégrité conceptuelle a été violée et nous le payons.

Je cite et traduis Ted Codd, père du Modèle relationnel :

Dans un contexte relationnel, les index sont des outils destinés à l'optimisation des performances et seront utilisés uniquement à cette fin... L'unicité des valeurs pour une colonne doit être spécifiée comme étant une propriété seulement de cette colonne et non pas celle d'un index. (E. F. Codd. The Relational Model for Database Management: Version 2 (Reading, Mass.: Addison-Wesley, 1990)).

Peut être un jour assisterons-nous à l’envoi à la décharge de tous ces index, quand par exemple nous utiliserons le TransRelational Model de Steve Tarin pour optimiser l’accès aux tables. Je vous renvoie à ce sujet à l’ouvrage de C.J. Date : An Introduction to Database Systems, 8th edition. (Pearson: Addison-Wesley (International Edition), 2004).

Ma question est :

En terme d'architecture : La pose de la condition UNIQUE correspond à la pause d'un index UNIQUE ? où c'est un mécanisme différent propre à sql serveur ?

[SQLpro]

La pose de la condition UNIQUE correspond à la pause d'un index UNIQUE ?

Vrai dans SQL Server comme dans la plupart des SGBDR !

Cela dit SQL Server ne respecte pas à la lettre la contrainte d'unicité car il n'accepte pas le multi null dans une contrainte UNIQUE et Nullable. C'est idiot et la communauté des développeurs SQL Server demande depuis longtemps que ceci soit modifié !

A +