Discussion :

[yannick069]

Bonjour,

J'ai un formulaire sur un site qui permet de mettre à jour le profil d'un utilisateur. Il se compose de plusieurs champs comme changement de mot de passe, changement / ajout date de naissance, lieu de naissance, paramétrage du site, etc. Ces différents champs de mon formulaire sont liés à des tables différentes dans MySQL. Ainsi:

• les informations de base (pseudo, mot de passe, etc) sont stockées dans la table MEMBRE
• les informations facultatives (date et lieu de naissance, etc) sont stockées dans la table MEMBRE_PROFIL
• les informations de paramétrage du site sont stockées dans la table MEMBRE_PARAM

Aujourd'hui lors du POST de mon formulaire, je teste quelles variables ont été modifiées:

Cas 1
si des variables de MEMBRE sont modifiées je fais une requête UPDATE sur la table MEMBRE

Cas 2
si des variables de MEMBRE_PROFIL sont modifiées, je fais une requête DELETE sur la table MEMBRE_PROFIL (car l'utilisateur peut avoir supprimé toutes les infos facultatives par exemple), puis une requête INSERT sur la table MEMBRE_PROFIL avec les valeurs du formulaire

Cas 3
si des variables de MEMBRE_PARAM sont modifiés, je fais une requête DELETE sur la table MEMBRE_PARAM (car l'utilisateur peut avoir supprimé tous les paramètres qu'il avait sauvegardé au préalable), puis une requête INSERT sur la table MEMBRE_PARAM avec les valeurs du formulaire

Ma question est: existe t-il un moyen de gérer tout ça plus facilement / efficacement en utilisant les procédures stockées ? Par exemple en évitant d'avoir systématiquement un DELETE suivi d'un INSERT dans le cas 2 & 3.

Je tiens à souligner que je n'ai jamais utilisé le SQL procédural donc j'y connais vraiment rien mais j'aimerai au moins avoir vos avis pour savoir si il est intéressant de regarder de ce côté pour gérer les mises à jour des tables de mon site dans ce cas précis.

Merci d'avance !

[ericd69]

salut,

déjà est bien nécessaire de séparer toutes ces information sur 3 table?

faut souvent ne pas penser interface=table...

avant de faire du procédural, ensuite, regarde la doc de mysql tu une syntaxe spécifique pour insert pour qu'un update soit fait à la place: ici donc pas besoin de delete puis insert...

donc il faut déjà peut-être revoir un peu la copie avant de passer au mode hard

teste déjà en version normal tout en tenant compte de ces remarques et là tu pourras voir à passer à un appel procédural pour minimiser les allers-retours php/mysql

[yannick069]

Merci pour ton avis ericd69

Je connais le ON DUPLICATE KEY UPDATE mais mon problème par exemple pour la table MEMBRE_PARAM, c'est que le nombre de lignes par membre peut changer. Je te donne un exemple:

- L'utilisateur peut choisir si il affiche la shoutbox ou non sur le site
- L'utilisateur peut choisir si il affiche sa liste d'amis ou non sur le site
- L'utilisateur peut choisir si il change la couleur ou non sur le site

• Un utilisateur qui n'a rien coché aura 0 ligne dans MEMBRE_PARAM et aura les options par défaut (rien d'affiché, couleur par défaut)
• Un utilisateur qui a coché d'afficher uniquement la shoutbox aura 1 ligne
• Un utilisateur qui a tout coché aura 3 lignes, une par option
• etc...

Donc quand l'utilisateur modifie ses paramètres j'ai 2 cas:
- Soit il met les options par défaut et dans ce cas je dois supprimer la ligne dans MEMBRE_PARAM
- Soit il met des options spécifiques et je dois faire in INSERT ou un UPDATE

Seulement imaginons que l'utilisateur avait 3 lignes dans MEMBRE_PARAM (car il a tout coché) et décide de ne cocher que l'option 1. Quand il sauvegarde je devrai avoir plus que la ligne pour l'option 1 et supprimer les 2 autres lignes, d'où mon idée de faire d'abord un DELETE suivi d'un INSERT.

Je ne pense pas y arriver avec le ON DUPLICATE KEY UPDATE. Ou alors il faudrait que je change ma logique et que je stocke dans tous les cas systématiquement une ligne par option (même si elle est décochée), ce qui me permettrait d'utiliser le ON DUPLICATE KEY UPDATE et dans ce cas chaque option prend un booléen 0 ou 1 pour cochée / décochée.

Est-ce mieux que faire des DELETE / INSERT ?

[ericd69]

faut voir les volumétries mais bon je pense que c'est plus simple et efficace que ton approche... après on en revient à pourquoi tu as besoin de séparer ces choses...

en gros, faut aussi penser en terme de ressources que tu crames (buffer de données, buffer d'index, pointeurs de fichiers nécessaires)

Là, si t'as que ça dans tes tables autan avoir une seule table... tu aurais eu un ensemble de colonnes texte peu utilisées par rapport au reste là oui, un partition de ta ble pour mettre ces colonnes à part se justifierait sur une grosse volumétrie et/ou fréquence de consultation... car tu éviterais de bufferiser ces textes pour rien trop souvent dans le buffer de données... donc il pourrait en ressortir une optimisation de l'accès par un moindre échange fichier/buffer...

sinon, en gros, ça sert à rien de faire ce que tu fais...
de plus l'insert...update est plus simple et efficace que des delete puis insert...

[yannick069]

Ok, merci pour tes conseils
Je vais voir pour fusionner MEMBRE et MEMBRE_PROFIL et garder seulement MEMBRE_PARAM dans une table séparée (car MEMBRE_PARAM peut avoir plusieurs lignes par membre, une par option activée, donc je ne veux pas dupliquer mes entrées de membre dans la table MEMBRE qui a l'attribut membre_id en PRIMARY KEY).