Update sql, avec une table à deux colonnes ...

Bonjour,

j'ai une table définie comme suit :

Code:

---

1 2 3 4 5 6

CREATE TABLE table ( config_name varchar(255) NOT NULL, config_value varchar(255) NOT NULL, PRIMARY KEY config_name (config_name) );

---

Et j'aimerais savoir s'il existe une façon d'updater plusieurs valeurs en une seule requète sur ce type de table.

Soit sans passer par une requète par valeur avec une requète du type :

Code:

---

1 2 3

$sql = "UPDATE table SET config_value = '$value' WHERE config_name = '$name'";

---

Parrallement je me demande si une meilleur definition de table ne conviendrait pas mieux à mon usage.

L'idée est d'utiliser cette table pour des valeurs de configuration d'un module, et d'en profiter pour y stocker quelques statistiques, cela evite une requète sur une eventuelle autre table en entrée de code (en plus mes stats ne concernent que 6 valeurs), mais j'aimerais trouver un moyen pour que l'update nécéssaire à chaque utilisation (à cause du comptage) soit lui aussi fait en une requète.

Je me demande si une table ayant autant de colonnes que de valeurs et une seule ligne ne serait pas plus adapté ?

En tous cas, merci à celui qui me donnera un indice.

++

première remarque en passant, si tu envisage sérieusement d'appeller une de tes tables Table, il vaut mieux rectifier ceci rapidement (cf Les mots-clé reservés du SQL)

Pour ta première question, il est possible d'affecter plusieurs lignes via un UPDATE si les mises à jour sont "génériques" :

Ex :

Code:

---

1 2	UPDATE maTable SET config_value = config_name;

---

ou

Code:

---

1 2	UPDATE maTable SET config_value = '1';

---

Mais dans ton cas, si les valeurs sont des paramètres bien distincts les uns des autres, j'ai peur qu'il te faille faire un UPDATE par paramètre.


En ce qui concerne ta deuxième question : si ta table est prévue pour recevoir des paramètres divers, il est bien entendu formement conseillé de les gérer ... comme tu le fais actuellement.
En effet, imagine que tu as 6 paramètres, et que tu te décides à les gérer via un seul enregistrement à 6 colonnes. le jour où les besoins changent, et que tu dois gérer de nouveaux paramètres, tu es obligé de modifier la structure de ta table : pas très évolutif :?

Merci pour ta réponse.

Et tinquiète ma table ne s'appelle ni ne s'appelera table, je prendrais un autre nom générique la prochaine fois ;)

Donc, c'est bien ce qu'il me semblait, pas moyen d'eviter une requète par paramètre.

Je sais que l'alternative que je propose est un peut "lourde", mais pas si impossible a faire evoluer que ça, on peut toujours ajouter des colonnes si on veut (elle ne ferait qu'une ligne de toute façon c'est pas les grands travaux).
Mon souci est ici la rapidité avant tout, et je me dis qu'il vaut mieux une table d'une seule ligne finallement, plutôt qu'une du type que j'évoquais ou même que deux table distinctes (une pour la config et une pour les stats rapides).

Vu que les paramètres à mettre à jour à chaque lancement du script sont somme toute peut nombreux, 9, et je ne pense pas aller au dessus de 12 (autrement j'ajouterais une autre table ;) ).

Qu'en penses tu, une table d'une ligne et uns vingtaine de colonnes, modifs eventuelles de structure mise à part, ce qui donne une requète en entrée, puis une en sortie, c'est plus rapide que deux requètes en entrée et une en sortie sur deux tables, la première pour la config (au passage il faut du coup un ti while pour agencer le tableau des resultats pour l'exemple cité) et la deuxieme pour les stats ?

Je me dis que oui, mais j'oublie sûrrement un paramètre ou deux pour bien me rendre compte.

++

J'en dis que :

Citation:

---

Mon souci est ici la rapidité avant tout

---

Tu n'as pas à t'inquiéter pour les performances : vu le faible volume de données gérées, quelle que soit la solution que tu choisisses, ça ne posera aucun souci ... à moins que tu parles de rapidité de codage ?

Du côté du modèle, je n'en démords pas : un enregistrement par paramètre, avec un code et une valeur, c'est le meilleur modèle à mon sens, puisque plus évolutif.
Imagine que tu les rendes accessible via un tableau et qu'on te demande de les classer, par ordre ou via un champ de type "famille" par exemple : avec le modèle que tu as actuellement, il te suffirait de rajouter une colonne pour gérer cette nouvelle notion. Avec le modèle à un seul enregistrement, comment vas-tu faire ? Tu vas dupliquer toutes tes colonnes ?
De plus, même si j'ai dis que les perfs n'étaient pas un souci, quand tu lis ou tu mets à jour un seul paramètre, il sera beaucoup plus rapide de manipuler un seul champ en y accédant via son code que de manipuler un enregistrement qui fait 10-15 colonnes.

Maintenant tu fais comme tu le sens ;)

Contrairement à ce qui t'a été dit, il est parfaitement possible de mettre à jour plusieurs lignes distinctes...

Il suffit pour cela d'un peu d'imagination.

Exemple :

Code:

---

1 2 3 4 5 6 7

UPDATE Ma_table SET config_value = CASE config_name WHEN 'toto' THEN 'A' WHEN 'titi' THEN 'B' END WHERE config_name IN ('A', 'B')

---

De plus ton modèle est bon. Faire une colonne par paramètre est stupide.
Tu peut cepandant rajouter à ta table de paramétrage une colonne indiquant le type (alpha, nombre, date...).

A +

hehe, je me demande c'est tout.

Encore une fois je n'aurais jamais (j'ai dis jamais moi ? :) ) d'autres infos à prendre dans cette table, par contre, j'entends le coté selection sur 20 colonnes.

D'un autre coté on dirait que SQLpro (bonjour ;) ) met tout le monde d'accord. Une requète c'est le top.

Ce que je voulais avant tout c'est eviter une rafalle de connections au serveur sql dans le code d'un script qui est tout de même censé réagir à des alertes de scans agressifs sur des sites, du coup tout gain de procedure est bon à prendre, l'envois d'une alerte peut vraiment se jouer à aussi peut je pense.

Donc merci à vous deux, et je teste cette merveilleuse formulation de SQLpro cette AM.


++

Citation:

---

Envoyé par dcz

Donc merci à vous deux, et je teste cette merveilleuse formulation de SQLpro cette AM.

---

Tu ne nous a pas précisé ton SGBD, CASE n'est pas implémenté partout :
cf http://sql.developpez.com/sqlaz/fonctions/#L1.8.

Ah, bah c'est mysql 4 et 3 en priorité.

D'après ce que je lis dans ton lien, c'est bon, dommage pour oracle, mais bon je pense que les utilisateurs d'oracle auront d'autres alternatives que mon script s'il peuvent financer une licence, y'aura aussi moyen de l'utiliser avec postgre apparement.

De toute façon je teste tout cela cette am.

Merci encore.

++

Donc,
Je viens d'essayer tout ça, et ça marche du tonnerre :) , bcp plus rapide qu'une serie de requètes.

Tout à fait ce que je recherchais donc, merci encore ;)

++