Utiliser ou non les proc stokées et triggers

Bonjour,

J'espère être dans la bonne partie du forum pour poser ma question un peu conceptuelle.
Je dois commencer un projet et j'hésite a mettre mon code en DB (SQL server) ou bien faire une application de type client/serveur en C# de façon traditionnelle.

Mon application est un suivi de biscuit et de machines a fabriquer des biscuits.
Pour simplifier, j'ai 3 machines : machine à faire la pâtes, machines à cuire et machine à emballer.
Et j'ai un biscuit que je dois suivre depuis qu'il est pâte jusqu'a ce qu'il soit emballé.
Ici je simplifie très fort....

J'imaginais donc 1 table par machine. La table est mise a jour automatiquement par les capteurs placés sur la machine.
Et j'ai une table biscuit avec un ID, un état, t° de cuisson, etc ...

Par trigger je pensais mettre en place mon suivi de flux.
Par exemple, lorsque je reçois un évènement sur ma table de la machine à cuire 'ouverture couvercle', je fais passer l'état de mon biscuit à 'en cuisson', etc...

Pensez-vous que c'est une utilisation judicieuse des triggers et proc stockées ?
J'ai vu sur certain site le pour et contre des developpements en DB mais pensez-vous que le developpement en DB peut se faire pour un suivi de flux ?
J'ai des craintes sur le debuggage par exemple.

merci

Bonjour,

Ce n'est pas évident de se situer par rapport à ton projet car en quelques lignes ce n'est pas évident de tout comprendre le fonctionnement.
Pour ma part, pour les quelques projets auxquels j'ai participé j'ai toujours travaillé avec un développement en DB.
Dans ton cas, je trouves que ce choix peut être judicieux car si tu dois brasser un grand nombre d'informations tu pourras (je penses) tout automatiser par trigger et/ou proc stockées.
Dans ce cas attention aux triggers quand même histoire de ne pas les lancer en cascade mais je penses ne rien t'apprendre vu que tu t'es déjà renseigné à ce sujet !

Pour le debuggage c'est sûr que de passer par des triggers et proc stockées peut être assez facilement problématique si tu n'arrives pas à suivre les traitements et prévoir tout les cas de figure. Si tout est bien paramétré tu ne devrais pas avoir trop de problèmes mais avant de lancer tout cela en production prévoit peut être une bonne phase de test en essayant d'insérer tout et n'importe quoi pour éviter de te faire poluer tes bases en cas de problèmes.. car une fois que tes bases ne sont plus très clean il devient très difficile de tout nettoyer (surtout si tu as beaucoup de données).

Donc ce n'est qu'un avis de ma petite personne mais je penses que ça peut être une bonne solution

merci pour ta réponse,

quelles sont les cas ou la programmation en db est à proscrire ?
je parle bien sur du code business, il est évident que l'on ne va pas construire des interfaces graphiques en db

Ben perso je suis aussi pour le dev en DB toutefois je dirais que ca dépend surtout de savoir se qui est le plus pertinant cad que si tu as beaucoup de calcule intermédiare complexe, c'est pas vraiment a ca que servent les DB, si il sagit de faire des opération assez basique en grand nombre avec un environnement trasactionnel, des journeau de log permetant de rétablir l'état éxacte à un moment X et beaucoup d'opération sur les ensemble là c'est clairement la BDD qui seras la plus performante...

En fait c'est juste des outils tout ca, le probléme reviens donc à choisir l'outil le plus adéquat et être pragmatique pas de savoir ce qui est le plus jolie.