Discussion :

[laurentSc]

Bonjour,

lisant des fichiers CSV, j'ai 3 options :

1- l'enregistrement n'existe pas dans la table MySQL, donc je l'enregistre (INSERT)

2- l'enregistrement existe dans la table (Son ID est présent), mais une des valeurs a changé : UPDATE

3- l'enregistrement existe dans la table (Son ID est présent), mais aucune valeur n'a changé : on fait rien.

Ma question est pour le cas n°2 : pour tester si une valeur a changé, pour chaque colonne, je pense faire un select COUNT(nom_colonne) WHERE nom_colonne='valeur_lue_dans_CSV' et si ça retourne 0, je fais un UPDATE. Est-ce la bonne façon de faire ?

[escartefigue]

Bonjour,

Non : ce n'est pas la bonne méthode.
Tout d'abord, sauf si la table a une seule colonne en dehors de l'id, il faudrait tester la valeur de chaque colonne dans une même requête pour vérifier que l'update est pertinent ou pas
Ensuite, le select de vérification n'a pas d'intérêt en terme de perfs (sauf si les mises à jour sont très marginales) et n'a de sens que si ce select pose un verrou interdisant la mise à jour : d'autre threads étant susceptibles de modifier la ligne entre le select et l'update.

[laurentSc]

Bonjour,
je ne comprends pas cette phrase :

que si ce select pose un verrou interdisant la mise à jour : d'autre threads étant susceptibles de modifier la ligne entre le select et l'update.

Ca veut dire quoi poser un verrou ?
Non, mes tables comportent plus de 2 colonnes ; en plus de l'ID (en AUTO-INCREMENT), 14 colonnes pour l'une et 17 pour l'autre.
Je sais pour chaque valeur du CSV dans quelle colonne de la table il va, mais ça ferait 14 select pour l'une et 17 pour l'autre. Donc selon toi, aucun intérêt et donc UPDATE, même si y a aucun changement ?

[escartefigue]

Le verrouillage est l'un des principes des SGBDR qui permettent, associé à la gestion des transactions, de gérer les concurrences d'accès.
Les verrous sont caractérisés par leur taille (ligne, page, table) et par leur type (partagé en lecture, en écriture, exclusif)
Si on fait un select sans verrou qui protège la mise à jour, rien n'empêche un autre utilisateur de modifier la ligne entre le select et l'update : du coup le select n'aura servi à rien.

Quant au select lui même, si on veut vérifier les écarts, il faut le faire sur toutes les colonnes en une seule requête, et faire l'update si au moins l'une des colonnes contient une valeur différente de celle du fichier CSV
Ce qui conduit à utiliser des OR et, comme dans une table il n'arrive jamais (fort heureusement !) que toutes les colonnes soient indexées, la requête sera très lente

Autrement dit, la requête pour tester qu'une mise à jour est requise ressemblerait à quelque chose comme

Code :

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

1
2
3
4
5
6
7
8
select col_identifiant
from ma_table
where col_identifiant = valeur_id_du_csv
 and (   col1 <> valeur_col1_du_csv
      or col2 <> valeur_col2_du_csv
      or col3 <> valeur_col3_du_csv
     ...
      or col4 <> valeur_col4_du_csv)

Le prédicat "<>" n'est pas SArgAble (pas indexable) donc ==> perfs catastrophiques