Discussion :

[bigben99]

Bonjour,

Je travaille actuellement sur une application devant gérer une base client.

Je dois donc stocker l'ensemble des clients dans une table et je pensais utiliser comme clé primaire, le résultat de la fonction md5() appliquée aux champs critiques permettant d'éviter au mieux la saisie de doublon.

voici ma table client :
cl_id varchar() : md5(nom + prenom + date_de_naissance)
cl_nom varchar(30)
cl_prenom varchar(30)
cl_datenaissance date

Cette methode est-elle selon vous acceptable ou existe-t-il des contre-indications ?

merci d'avance

[fsmrel]

Comment ferez-vous si deux clients ont mêmes nom, prénom et date de naissance ?


Il est d'usage de retenir pour les clés primaires des attributs invariants, non porteurs d'information et dont vous avez la maîtrise totale.


Autrement dit, faites comme tout le monde, mettez en oeuvre un nouvel attribut qui soit identifiant, appelez-le par exemple IdClient et affectez-lui le type entier (ou équivalent), en incrémentant cet attribut à chaque fois que vous créez une ligne dans la table Client. Je pense que SQLpro doit proposer sur ce site pas mal de solutions allant dans ce sens.

[bigben99]

Comment ferez-vous si deux clients ont mêmes nom, prénom et date de naissance ?


Il est d'usage de retenir pour les clés primaires des attributs invariants, non porteurs d'information et dont vous avez la maîtrise totale.


Autrement dit, faites comme tout le monde, mettez en oeuvre un nouvel attribut qui soit identifiant, appelez-le par exemple IdClient et affectez-lui le type entier (ou équivalent), en incrémentant cet attribut à chaque fois que vous créez une ligne dans la table Client. Je pense que SQLpro doit proposer sur ce site pas mal de solutions allant dans ce sens.

Les trois attributs nom, prenom, date de naissance n'étaient qu'un exemple de tuple constituant ma clé primaire.

Mon objectif est surtout d'éviter au maximum la saisie en double de client.
Sachant que dans ma base, un client a environ une quarantaine d'attributs mais seulement 5 qui permettent de l'identifier de façon unique.
Une comparaison lors de la saisie d'un client de ces 5 attributs avec ceux de l'ensemble des clients dans la base (200.000) est assez gourmande en ressource. Donc je pensais faire une tentative d'insertion du client avec comme clé primaire le md5(att1 + att2 + ... + att5) du nouveau client. Si l'insertion se passe bien, c'est que mon client est nouveau, si l'insertion se passe mal, c'est que mon client existe déjà (probabilité que ce ne soit pas un doublon de 99,99%)

[fsmrel]

Bonsoir Bigben,

Si à l’ensemble K d’attributs {att1, att2, ..., attm} d’une table R on associe une contrainte d’unicité, telle que deux lignes de R ne peuvent pas avoir la même valeur pour K, alors K est ce que l’on appelle une surclé de R. Si en plus le fait retirer de K l’un quelconque de ces attributs fait que la contrainte d’unicité ne peut plus être garantie, alors K est une clé candidate pour R.

La table R peut comporter plusieurs clés candidates. Dans un contexte SGBD relationnel, il est d’usage de retenir une de ces clés candidates pour être clé primaire (de même que parmi un ensemble de prétendantes au titre, il n’y en a qu’une qui sera miss France). Pour le bien de la base de données, cette clé primaire, appelons-la PK, doit posséder certaines vertus : être invariante (ne pas changer de valeur) et ne pas être significative (porteuse d’information pour l’utilisateur). Ça n’est pas un absolu, mais une règle d’hygiène.

Comme je le rappelle fréquemment ici, imaginez cent tables de cent millions de lignes en moyenne, dont il faille remplacer des valeurs de clés primaires : si par exemple il s’agit pour ces cent tables du numéro INSEE et que l’INSEE vous envoie 10% de correctifs par mois, alors la production informatique peut exploser. Hors de question de faire du numéro INSEE une clé primaire, intervenant dans les relations d’intégrité référentielle entre tables, comme étant une référence pour les clés étrangères.

De même qu’il y a une miss et des dauphines, il y a une clé primaire pour R et des clés alternatives : clés candidates non élues, mais pour lesquelles la contrainte d’unicité joue toujours. Au niveau de l’instruction Create Table, vous leur associez une contrainte UNIQUE.

Ce qui donne, pour en revenir à votre exemple, quelque chose ressemblant à ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Create Table Client
(
    IdClient    ...,
    att1        ...,
    att2        ...,
    attm        ...,
    attm+1      ...,
     ...        ...,
    attn        ...,
  Primary Key (IdCLient),
  Unique (att1, att2, ..., attm)      /* Clé alternative */
;

Clé primaire ou clé alternative, comme vous l’évoquez, si l'insertion se passe bien, c'est que le client est nouveau, si l'insertion se passe mal, c'est que le client existe déjà.

Cela dit, vous évoquez un aspect performance (consommation de ressources). Que vous effectuiez un Select ou un Insert, c’est au niveau physique que cela joue, qu’il s’agisse de clé primaires ou alternées. En l’occurrence l’existence des index qui vont bien est déterminante.

[bigben99]

merci pour ces explications

je vais donc suivre vos recommandations et créer ma table client avec 1 clé primaire (autoincrémentée) pour les relations avec les autres tables et 1 clé alternative (unique) pour les attributs client me permettant de garantir l'unicité.