Discussion :

[dmk04]

Bonjour,

Je voudrais savoir s'il est risqué de stocker des requêtes SQL dans une table ? Si oui, pourquoi (si possible) ?

Merci d'avance,

Marc

[Fabien Celaia]

Disons que c'est exactement ce que fait le sgbdr lui-même pour ses objets compilés...

La question, c'est plutôt pourquoi ? Si c'est pour de la réutilisation, autant faire de la procédure stockée ou des vues.

[dmk04]

C'est pour une application PHP/MySQL.

Pour l'utilisation : c'est assez compliqué (je pense), mais je vais essayer de simplifier la situation.

Disont que j'ai une table d'utilisateurs, répartis dans plusieurs groupes. Chaque utilisateur a un poste (exemples : chef du "groupe père", chef du groupe, chef second, technicien, comptable, simple membre du groupe...). J'ai une table avec les différents postes répertoriés.
Des groupes peuvent etre "chef" d'autres groupes (j'ai donc un champ "groupe père" dans ma table groupe). J'ai une autre table avec différents "chemins" que les informations doivent suivre. Cette table a 3 champs : "type" du chemin, numéro de l'étape, poste (de la personne à laquelle on doit transmettre l'information).
Voilà le minimum pour comprendre je pense.

Voici maintenant un exemple pour illustrer ce que je veux faire :
Un membre à une information, il veut la faire circuler. Suivant le "type" d'information (qu'il aura choisit), l'information ne va passer par les mêmes personnes dans le groupe. On a donc une information, un type d'information, et pour savoir à qui on doit transmettre cette information, on accède à la table "chemins". A partir de l'information, de l'étape en cours (que l'on peut trouver à partir de l'information), et du type d'information, je peux le "poste" de la persone à contacter. Mon probème est : trouver l'utilisateur qui correspond à ce poste dans le groupe.
Ce que je ne veux pas faire : coder en "dur" un truc du genre "switch(poste){case "chef" : .... case "technicien"...}". Je pensais donc rajouter un champ "requete" à ma table "postes" dans laquelle je stockerai la requête pour trouver l'utilisateur. Au moment de trouver l'information pour trouver l'utilisateur à qui l'information doit être transmise, je chargerais la requête correspondant au "poste" de de l'étape ma table "chemins" et l'éxécuterai, pour trouver l'utilisateur.

Si certains points ne sont pas clair, dites-le moi, j'essayerai de mieux les expliquer.

Merci d'avance.

[dmk04]

Salut,

Je crois que le gros block fait peur à des gens... Pas de réponses ???

Ce que je veux savoir :
Est-il dangereux de stocker dans le champ d'une table, un truc du genre :
"SELECT id_usr FROM user WHERE gr_user='".$gr."';"

Merci pour vos réponses.

[Mercure]

Un bon exemple valant toujours mieux qu'un long discours, je te suggère de nous donner plutôt un exemple de

• la définition de tes tables en entrée,
• un échantillon des données qu'elles contiennent,
• les colonnes a rapprocher entre les tables en entrée
• la définition de la table en sortie
• le résultat que tu veux obtenir dans cette table

Egalement, expliquer ce qu'il y aurait de dangereux là-dedans...

[dmk04]

Salut,

Merci d'avoir répondu.
Alors, j'essaye de gérer un workflow.

Quelques tables et exemples de contenu.
J'ai enlevé les tables de droits, contenu des demandes d'investissements, validation et demandes d'informations complémentaires qui ne nous interressent pas dans ce cas.

groupes :
- id_gr (PK)
- id_resp
- id_gr_pere
Exemples :
100 S1 NULL
101 R1 100
102 R2 100
150 I1 NULL
170 D1 NULL

utilisateurs :
- id_user (PK)
- id_gr (FK[groupes] PK)
- id_cat (FK[categories])
Exemples :
S1 100 SUP
R1 101 RESP
I1 150 INFO
I2 150 INFO
D1 170 DIR
U10 101 USR
U11 101 USR
U20 102 USR
U21 102 USR

categories :
- id_cat (PK)
Exemples :
RESP
INFO
DIR
USR

demandes_invest :
- id_dde_inv (PK)
- id_user (FK[utilisateurs])
- id_gr (FK[utilisateurs])
- id_nature (FK[natures])
- etape_en_cours
Exemples :
001 U1 101 INF 1

natures :
- id_nature (PK)
Exemples :
INF
MAT

workflow :
- id_nature (FK[natures] PK)
- id_etape (PK)
- id_cat (FK[categories])
Exemples :
INF 1 RESP
INF 2 SUP
INF 3 INFO
INF 4 DIR
MAT 1 RESP
MAT 2 SUP
MAT 3 DIR

Alors :

Nous avons différents groupes, certains groupes on un groupe au dessus d'eux.

Nous avons des utilisateurs qui appartiennent à différentes catégories (RESP pour responsable d'un groupe, SUP pour responsable d'un groupe qui "domine" d'autres groupes, INFO pour un informaticien, USR pour les utilisateurs, DIR pour la direction...). Les utilisateurs sont ratachés à un groupe. id_gr est clé primaire, car il y a quelques rares doublons dans les id_user...
Suivant la catégorie de l'utilisateur, il n'a pas les mêmes droits (table non représentée).

Un utilisateur peut émettre une demande d'investissement. Cette demande d'investissement est donc rattachée à cet utilisateur. Les demandes d'investissement ont une nature (ici INF pour informatique, et MAT pour du matériel).

Suivant la nature de la DI (demande d'investissement), le cheminement n'est pas le même :
Pour des DI INF : la DI va passer par le RESP, puis SUP, puis INFO, puis DIR.
Pour des DI MAT : la DI va passer par le RESP, puis SUP et DIR.



Mon problème est de trouver une requête qui me dira que pour la DI 001 (crée par U1 dans le groupe 101, de nature INF et en est à l'étape 1 ) :
- devra aller chez R1 (qui est le RESP de 101)
Ca c'est simple, mais le problème, c'est que cette même requête devrait me dire que pour l'étape 2 elle doit allez chez S1 (qui est le SUP de 101), pour l'étape 3 I1 ou I2 (qui sont les informaticiens : INFO), et D1 (qui est la direction : DIR).

Il est possible de changer mon modèle de données.



Pour expliquer ce qu'il y a de dangeureux la dedans : je n'en sais rien, c'est ce que je demande ! Je demande si ce serais une "faille" de stocker une requête dans une table.


Si je ne suis pas clair, dites le moi.

Merci.

[SQLpro]

Je demande si ce serais une "faille" de stocker une requête dans une table.

Ce n'est pas de cette manière là qu'il faut raisonner.

Si l'on peut faire cela uniquement par la modélisation, alors ce sera toujours mieux.

Si le modèle est difficile à monter (par exemple schéma ayant des changements très fréquents) alors stocker des requêtes dans des tables contitut un pis aller acceptable.

A +

[dmk04]

Ok,
merci.

++