Discussion :

[GuiDjad]

Bonjour,

Pour améliorer la rapidité d'exécution d'une requête SELECT, qu'elle est le choix le plus judicieux entre utiliser un CHAR comme clé primaire ou utiliser un INT comme clé primaire et un CHAR comme attribut avec la contrainte UNIQUE. Ce qui revient au même question résultat mais quelle choix propose un temps d'exécution optimisé?

Merci d'avoir lu ce message

[CinePhil]

Un entier est codé sur 4 octets.
Un CHAR est codé sur autant d'octets que la longueur du CHAR.

C'est à tester mais je pense que jusqu'à CHAR(4), les performances seront équivalentes. Au-delà, on préférera l'entier.

Pour plus d'arguments en faveur de la clé auto-incrémentée donc entière, voir l'article de SQLPro.

[GuiDjad]

D'accord mais le fait qu'on utilise deux attributs à la place d'un n'a t-il pas d'influence aussi?

[fsmrel]

Bonsoir,


Comme disait Guillaume d’Ockham :

Pluralitas non est ponenda sine necessitate.

Autrement dit, pourquoi deux attributs dont l’objet est le même, à savoir garantir l’unicité des tuples d’une relation ? Si c’est pour gagner une demi-milliseconde pour une requête dont la durée est d’une seconde, une minute, une heure ou un jour, et au-delà, quel intérêt ?
Attention aux mises à jour, une clé primaire + une contrainte UNIQUE => doublement des index => durée des mises à jour multipliée au moins par deux fois le nombre de relations auxquelles vous infligeriez ce traitement. Bref, soyez parcimonieux.

Comme dit CinePhil : la clé primaire ne doit pas être imposée par l'utilisateur. Si tel était le cas, alors seulement vous doublez sa clé (UNIQUE) par votre clé primaire bien à vous, invariable et sans signification, dont seul le système a la responsabilité. A ce sujet, je vous renvoie à l’élection de Miss Clé primaire.

[GuiDjad]

Attention aux mises à jour, une clé primaire + une contrainte UNIQUE => doublement des index => durée des mises à jour multipliée au moins par deux fois le nombre de relations auxquelles vous infligeriez ce traitement. Bref, soyez parcimonieux.

Comme dit CinePhil : la clé primaire ne doit pas être imposée par l'utilisateur. Si tel était le cas, alors seulement vous doublez sa clé (UNIQUE) par votre clé primaire bien à vous, invariable et sans signification, dont seul le système a la responsabilité. A ce sujet, je vous renvoie à l’élection de Miss Clé primaire.

Bonsoir,

Pour les mises à jour, la clé primaire n'est pas censé être mise à jour comme tu l'as dis dans ton post du Miss Clé primaire (Stabilité) . Mais si je suis ce que tu dis dans ton post:

Dans l’exemple ci-dessus, par hypothèse {MbrId} garantit ces deux critères et sera élue Miss clé primaire. Ses dauphines, à savoir {Pseudonyme} et {AdrCourriel} seront ravalées au rang de clés alternatives.

Il est mieux de mettre un INT en clé par clé primaire et de mettre Pseudonyme et AdrCourriel en UNIQUE. C'est le contraire de ce que tu m'as dit au dessus

[fsmrel]

Bonsoir,

Pour les mises à jour, la clé primaire n'est pas censé être mise à jour comme tu l'as dis dans ton post du Miss Clé primaire (Stabilité)

Par mise à jour j’entends INSERT, DELETE et UPDATE. Dans le cas d’un insert ou d’un delete, l’index associé à la clé primaire est mis à jour.

Il est mieux de mettre un INT en clé par clé primaire et de mettre Pseudonyme et AdrCourriel en UNIQUE. C'est le contraire de ce que tu m'as dit au dessus

Je ne suis pas sûr d’interpréter correctement ce que vous écrivez car vous donnez l’impression de juger de l’intérêt d’un type (INT en l’occurrence) par rapport à une contrainte (UNIQUE). En tout état de cause, pour parler SQL, une table n’a droit qu’à une seule clé primaire (clause PRIMARY KEY), tandis qu’elle peut avoir plusieurs clés alternatives (clause UNIQUE) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
CREATE TABLE Membre
(
    MbrId        ...
  , Pseudonyme   ...
  , AdrCourriel  ...
   ...
  , CONSTRAINT Membre_PK PRIMARY KEY (MbrId)
  , CONSTRAINT Membre_AK1 UNIQUE (Pseudonyme)
  , CONSTRAINT Membre_AK2 UNIQUE (AdrCourriel)
   ... 
) ;

Quant à utiliser le type INT ou le type CHAR pour MbrId, c’est affaire de goût, de parcimonie, etc. Bien entendu, Pseudonyme et AdrCourriel ne seront pas du type INT.

Pour mémoire, la notion de clé primaire a disparu de la théorie relationnelle (à juste titre, Guillaume d'Ockham a encore frappé) :

Code D :

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

1
2
3
4
5
6
7
8
9
10
11
 
VAR Membre BASE RELATION
{
    MbrId        ...
  , Pseudonyme   ...
  , AdrCourriel  ...      
  ...
}
KEY {MbrId}
KEY {Pseudonyme}
KEY {AdrCourriel} ;