Discussion :

[lerieure]

Bonjour,

Dans mon trigger sur INSERT j'exécute une mule
le problème vient évidemment des boucles en plus sur des tables temporaires (une mise à jour fera en sorte de plus être sur des tables temporaires mais le code restera le même avec des boucles...)

Que fait le Trigger ?
Lors d'un ajout de règle, il recherche les règles qui peuvent être impactées car la table qui exécute le trigger contient des règles permettant de générer un planning. Il doit garder la cohérence et l'intégrité de ces règles (insert,update,delete)

chaque ligne de la table qui contient les règles contient une machine, une station, des plannings (et sous plannings), un calendrier, un lieu (et des sous lieux), un programme (ensemble de machine) et un programme a des sous programmes... Il ne peut pas avoir dans une règle une machine et un programme de renseignés en même temps
si un champ contient null alors ça veut dire que c'est pour tout :
si calendrier est null alors la règle devra générer le suivi pour tout les calendriers

le suivi est générer que si lors de la recherche des règles impactées il y a assez de données pour pouvoir être générée

MACHINE PROGRAMME LIEU PLANNING STATION CALENDRIER
null 2 5 2 null null <- dans la table
null null 8 null 3 null <- dans la table
null null 20 40 null null
2 1 <- règle ajoutée

le programme 2 inclut la machine 2
le lieu 5 inclut 8 et 8 est plus précis

ma règle final sera donc
MACHINE PROGRAMME LIEU PLANNING STATION CALENDRIER
2 null 8 2 3 1 <- regle valide
2 null 20 40 null 1 <- regle non valide on a pas trouvé de station...

Après on va récuperer les valeurs les plus précises de mes lieux (les feuilles de mon arbre), idem pour planning et générer plusieurs lignes
(qui va créer x lignes dans une autre table)

Bien sur il y a d'autre propriété comme les dates etc... mais si vous voyez comment je peux éviter les boucles dans mon trigger
votre aide sera énorme pour moi sachant que je dois rendre la chose dans pas longtemps.

Merci votre aide

[elsuket]

Bonjour,

Je suppose que vous faites suite à la discussion suivante.

chaque ligne de la table qui contient les règles contient une machine, une station, des plannings (et sous plannings), un calendrier, un lieu (et des sous lieux), un programme (ensemble de machine) et un programme a des sous programmes... Il ne peut pas avoir dans une règle une machine et un programme de renseignés en même temps

C'est donc que votre modélisation n'est pas bonne, et cela se voit dans le code de votre trigger.
A partir de cette phrase, vous devriez avoir :

- une table programme, avec colonne NULLable dans laquelle vous renseignez éventuellement l'identifiant du programme parent, avec une contrainte de clé étrangère sur la table elle-même
- une table machine, avec une contrainte de clé étrangère référençant la table des programmes (sauf si une machine peut appartenir à plusieurs programmes, auquel cas il vous faudra une table supplémentaire)
- une table station (une station appartient-elle à une machine ou une station permet-elle de contrôler un ou plusieurs machines ?)
- une table planning avec une colonne NULLable dans laquelle vous renseignez éventuellement l'identifiant du planning parent, avec une contrainte de clé étrangère sur la table elle-même
- une table calendrier
- une table lieu avec une colonne NULLable dans laquelle vous renseignez éventuellement l'identifiant du lieu parent, avec une contrainte de clé étrangère sur la table elle-même

si un champ contient null alors ça veut dire que c'est pour tout

C'est surtout là que c'est faux et qu'il y a un défaut d'intégrité : vous devriez avoir une table représentant les relations entre toutes les tables de la liste précédente, dans laquelle vous mettez en relation tous les éléments qui constituent une règle.

Là encore le modèle n'est pas le même si une machine peut appartenir à plusieurs programmes ou si plusieurs programmes peuvent être exécutés par une machine.
Il en va de même avec les stations et les lieux.

Si vous ne passez pas par cette phase de définition des entités et des relations de ce que vous voulez représenter, vous resterez cloîtré dans le trou noir des triggers de plus de 1000 lignes avec des boucles et/ou des curseurs, le tout totalement contre-performant, ingérable et peu ou pas flexible.

Donc le temps que vous passerez à modéliser votre base de données est forcément bien moins long que le temps que vous passerez à vous prendre la tête pour maintenir / faire évoluer le planning.
En plus de cela vous apprendrez à modéliser, et vous aurez le temps de bosser sur autre chose

Une fois la modélisation réalisée, le code de votre trigger sera d'une simplicité énorme par rapport à votre trigger actuel, et s'exécutera rapidement.

Je reprends la discussion précédente :

le problème étant que je dois développer des fonctionnalités dans un labbe de temps court en n’ayant aucun cahier des charges et l'utilisateur ne veut pas avoir de web service, WCF et ni codé la fonctionnalité dans une application, car il y a plusieurs applications dans plusieurs langages donc trop longs pour lui.

Il n'y a ni besoin de web service, ni de WCF, ni même peut-être d'appli.
Vous pouvez utiliser SQL Server Reporting Services (SSRS) qui est livré avec SQL Server dans les éditions Developer, Standard et Enterprise.
En revanche il sera plus compliqué de réaliser les modifications de données à partir de SSRS.

Nous pouvons vous aider à réaliser le modèle de données, mais il faut que vous définissiez ce qu'est un programme, une machine, une station, un planning, un calendrier, ... et les relations entre ces entités.

@++

[lerieure]

C'est donc que votre modélisation n'est pas bonne, et cela se voit dans le code de votre trigger.

pour cette partie, j'ai utilisé ce modèle http://sqlpro.developpez.com/cours/arborescence/

qui a l'air d'être plus adapté dans le contexte


Pour ce qui est des relations entre toutes les tables ils faut bien que l'utilisateur ne saisisse pas toutes les lignes sinon il n'y a pas de gain de temps

C'est surtout là que c'est faux et qu'il y a un défaut d'intégrité

une fois les règles générées elles sont mises dans une table qui n'a pas de défault d'intégritée

quand il met null c'est que le système doit prendre toutes les id de la table qu'il fait référence en clé étrangère
et les écrires dans une table normalisée

TABLE A
A_ID 1
A_ID 2
A_ID 3

A_ID B_ID
user saisit une ligne-> null 1

qui génère :
A_ID B_ID
1 1
2 1
3 1

Donc gain de temps pour l'utilisateur qui se frappe pas les n lignes non?
qu'en pensez vous?

Nous pouvons vous aider à réaliser le modèle de données, mais il faut que vous définissiez ce qu'est un programme, une machine, une station, un planning, un calendrier, ... et les relations entre ces entités.

c'est déjà fait

T_ARBO_PLANNING : PLANNING_ID, PLANNING_BG, PLANNING_BD, PLANNING_LEVEL, PLANNING_NAME

T_ARBO_LIEU : LIEU_ID, LIEU_BG, LIEU_BD, LIEU_LEVEL, LIEU_NAME

T_ARBO_PROGRAMME : PROGRAMME_ID, PROGRAMME_BG, PROGRAMME_BD, PROGRAMME_LEVEL, PROGRAMME_NAME

T_ARBO_STATION : STATION_ID, STATION_BG, STATION_BD, STATION_LEVEL, STATION_NAME


(voir le lien de l'arborescence intervallaire de sqlpro ci-dessus)

T_MACHINE : MACHINE_ID, moteur...

TASK : TASK_ID, #PLANNING_ID, #LIEU_ID, #MACHINE_ID, #STATION_ID, DATE_DEBUT, DURATION, DATE_FIN
ICI RIEN NE PEUT ETRE NULL, cette table reçoit la génération faite par le trigger

T_PROGRAMME_MACHINE : #MACHINE_ID, #PROGRAMME_ID

LA TABLE PAS INTEGRE AVEC LEDIT TRIGGER
T_TEMPLATE : #TEMPLATE_ID, #PLANNING_ID, #LIEU_ID, #PROGRAMME_ID, #MACHINE_ID, DATE_DEBUT, DURATION, DATE_FIN
ICI TOUT PEUT ETRE NULL sauf TEMPLATE_ID et des contraintes uniques de règle qui ne peuvent pas être redondante, cette table c'est ce qu'a saisit le user

voila une partie de la base, je n'ai pas mis toutes les propriétés et les indexes et clés uniques... mais si vous les voulez je peux les ajouter.

[SQLpro]

Une fois la modélisation réalisée, le code de votre trigger sera d'une simplicité énorme par rapport à votre trigger actuel, et s'exécutera rapidement.

Je pense même qu'il n'aura aucun besoin de trigger !
Un des exemples que je donne dans mon cours de modélisation est justement de modifier le modèle pour ne plus avoir de trigger lorsque par exemple on veut contrôler une cardinalité, par exemple par limitation. (exemple, un adhérent d'une bibliothèque ne dois pas emprunter plus de 3 livres....)

A +

[elsuket]

SQLPro,

Je suis entièrement d'accord avec toi, c'est d'ailleurs ce que j'avais commencé à écrire et je l'ai effacé pour la raison suivante :

'utilisateur ne veut pas avoir de web service, WCF et ni codé la fonctionnalité dans une application

Les données doivent bien arriver dans la base de données d'une quelconque façon.
Si ce n'est pas par un applicatif, est-ce manuel ?

@++

[lerieure]

Les données doivent bien arriver dans la base de données d'une quelconque façon.
Si ce n'est pas par un applicatif, est-ce manuel ?

ce serait par un SSIS via un fichier Excel ou txt. D'ailleurs j'ai posté un message ici et j'ai toujours pas eu de réponse... Je sais pas si c'est le bon endroit?

Je suis dans le pétrin