Discussion :

[hartecel]

Bonjour,

Je suis entrain de créer un site internet avec un espace client. Pour ce faire, j'ai crée sous mysql une table client :

CLIENT(codeClient,nomClient,...,loginClient,passClient)

J'ai choisi comme clé primaire "codeClient". Je me trouve confronter à un problème. Deux client peuvent avoir le même login et le même mot de passe. ALors, je me demandais si je devais pas prendre comme clé primaire loginClient et passClient.
Mais, en faisant ça, je me retrouve face à un autre problème si je veux faire une partie "modification des infos du client". En effet, je ne sais plus comment faire ma requete update ... je ne sais plus quoi mettre dans le where.

qqn a une solution ?

[Purple Haze]

Salut !!!
Il faut que tu attribut un identifiant unique pour chaque client, c'est plus simple et plus sûr, et ça peut éviter des problèmes.

[hartecel]

Salut !!!
Il faut que tu attribut un identifiant unique pour chaque client, c'est plus simple et plus sûr, et ça peut éviter des problèmes.

Merci pour ta réponse.
Tu penses que c'est mieux d'utiliser un codeClient ? Mais comment éviter qu'il y ait deux clients avec le même compte ?

[Purple Haze]

A partir du moment où l'identifiant du client est unique, chaque compte client sera unique.
Soit tu utilises l'identifiant qui est automatiquement insèré à chaque enregistrement (ID, NomClient, LoginClient, etc...), soit tu rajoutes un code client qui permet une identification du client indépendament de son identifiant (ID, CodeClient, NomClient, LoginClient, ...)

[fsmrel]

Bonjour hartecel,


Une clé primaire est un cas particulier de ce qu’on appelle une clé candidate, concept dont je traite dans une discussion du forum Général SGBD : "Unicité d'une clef composée", voir mon message du 20/02/2007, 12h36.

Supposons qu’outre l’attribut CodeClient (que vous avez retenu pour la clé primaire), LoginClient soit contraint à être unique (deux personnes ne peuvent avoir le même login), l’instruction Create Table Client ressemblera à ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
 CREATE TABLE Client
  ( 
    CodeClient ... ,
    NomCLient ...  ,
    LoginClient ...,
    PassClient ... ,
    ...            ,
   PRIMARY KEY (CodeClient),
   UNIQUE      (LoginClient)
  ) ;

Si vous souhaitez faire des UPDATE, par exemple modifier un nom de client et son login, vous pouvez coder :

Code :

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

1
2
3
 Update Client
    SET LoginClient = "hartesucre", NomCLient = "Jean du Harte Sucre" 
    WHERE  LoginClient = "hartecel" ;

[PierreDelcroix]

Moi, j'utilise toujours des champs numérotés automatiquement (autoidNr ) et je n'ai jamais de problèmes.

[siplusplus]

J'utilise aussi une clé qui s'incrémente automatiquement.
Eviter autant que possible les clés composées
(si un attribut disparait, la clé contiendra forcément des doublons).
Et j'utilise rarement des clés primaires provenant de tiers
car on ne sait pas si on aura ou non des doublons.

[fsmrel]

Moi, j'utilise toujours des champs numérotés automatiquement (autoidNr ) et je n'ai jamais de problèmes.

Certes, vous pouvez procéder ainsi et c’est même conseillé pour les clés primaires, ce qui est le cas pour l’attribut codeCLient de la table Client de Hartecel. Mais, dans le cas de l’attribut loginCLient, si c’est le client qui choisit son login, par exemple "PierreDelcroix" : premier arrivé, premier servi. Si vous ne voulez pas qu’il y ait deux "PierreDelcroix", l’attribut loginClient est alors clé alternative prenant des valeurs distinctes, contrainte que vous garantissez à l’aide de la clause UNIQUE dans l’instruction Create Table (cf. l’exemple figurant dans mon message précédent).

Eviter autant que possible les clés composées
(si un attribut disparait, la clé contiendra forcément des doublons).

Si vous pensez que les clés composées sont à éviter, vous avez certainement de bonnes raisons pour cela à nous exposer (je ne sais pas ce que vous entendez par la disparition d’un attribut. Quoi qu’il en soit, si vous utilisez une clause Unique pour signaler une clé candidate, quelle soit simple ou composée, le SGBDR interdira la présence de doublons).

Par ailleurs les clés composées sont inévitables quand elles sont la conséquence d’associations M-N au niveau conceptuel. Qui plus est, elles peuvent être bénéfiques au niveau de l’exécution des programmes, garantissant la synchronisation du parcours des pages de données de tables distinctes, donc une diminution sensible, voire l’élimination de l’effet I/O bound (attentes de fin d'entrées-sorties). Quand les tables représentent des dizaines de millions de lignes, cela devient décisif pour les grands batch de nuit et du week-end, sans oublier les transactions brassant beaucoup de lignes.

Quand à effectuer des update d’une clé alternative, simple ou composée, aucun problème, dès lors que vous ne tentez pas d’introduire des doublons.