Populate plusieurs champs avec une même valeur

**dedis** · 24/03/2011, 14h36

Bonjour,

Je réalise un bête formulaire de modification d'une ligne dans une table SQL. Je n'utilise pas d'id auto-incrémentable, mais le champs 'name' comme clef primaire.

Donc, dans le formulaire, j'ai un champs texte 'Name' qui se remplis automatiquement avec la bonne valeur. L'utilisateur peut le modifier.
Toutefois, pour pouvoir appeler la ligne à modifier lors de l'envoie du formulaire, je veux stocker le Nom d'origine dans un input hidden appelé 'old name'.

Donc, mes champs de formulaire Name et Old Name doivent être remplis avec la même valeur name par populate.

Comment faire ?

**s.n.a.f.u** · 25/03/2011, 19h22

Salut,

Tu es devant un problème de conception.
La clef primaire ne devrait pas être modifiable par formulaire (ni par un autre moyen d'ailleurs).

Ne peux tu pas changer le schéma de la base donnée ?

**dedis** · 26/03/2011, 14h25

Merci de m'éclairer

J'essaie de coder de plus en plus propre, et je suis prêt à prendre en compte toutes les remarques de ce type.

Je peux utiliser des id auto incrémentés. Toutefois, il me semble que les index se mettent en place automatiquement sur les clefs primaires. Or, avoir un index sur un id n'est pas très intéressant, puisque la majorité des requêtes vont consister à faire des recherches sur les clefs primaires 'naturelles' (nom, titre, etc.). C'est encore plus vrai pour les tables de relations. De plus, cela permet de véritablement exploiter les fonctions du SGBD du type contrôle des doublons etc.

Bref, je ne suis pas persuadé que mettre des ids auto incrémentés partout soit une très bonne pratique. Sur quoi est basé le principe de ne pas permettre à l'utilisateur de modifier les clefs primaires ?

**s.n.a.f.u** · 26/03/2011, 15h03

Envoyé par dedis

Sur quoi est basé le principe de ne pas permettre à l'utilisateur de modifier les clefs primaires ?

C'est surtout pour le maintien de l'intégrité de ta base de données.
En effet, mettre à jour une clef primaire va t'obliger à cascader sur toutes les tables qui utilisent cette clé comme clé étrangère.

Pour ce qui est de maintenir tes contrainte d'unicité, les indexes uniques sont faits pour cela.

La majorité des requêtes vont consister à faire des recherches sur les clefs primaires 'naturelles' (nom, titre, etc.). C'est encore plus vrai pour les tables de relations.

Lorsqu'il s'agit de relations, les recherches porteront sur l'id (qui sera une clé étrangère pour les autres tables), ce qui est très performant.