31,029
edits
Tag: 2017 source edit |
Tag: 2017 source edit |
||
| Line 295: | Line 295: | ||
De telles instructions SQL sont interdites car elles contournent les règles métiers de l'application. Par exemple, s'il existe une cascade de suppression entre la table A et B, lorsque l'application exécutera le code pour supprimer un enregistrement dans A, les enfants de la table B seront également supprimés. S'il y a eu un trigger Dolibarr PHP (par exemple apporté par un module externe) sur la suppression de l'enregistrement de B (par exemple pour valider la suppression ou pour exécuter une action complémentaire), la DELETE CASCADE sera exécutée sans avoir le trigger Dolibarr PHP exécuté, manquant la validation ou les actions du déclencheur PHP du module. Donc toutes les règles métiers doivent être implémentées du même côté (côté serveur PHP), c'est la raison pour laquelle les règles métier implémentées sur Database ne sont pas autorisées (même situation que le point suivant sur les triggers Database) | De telles instructions SQL sont interdites car elles contournent les règles métiers de l'application. Par exemple, s'il existe une cascade de suppression entre la table A et B, lorsque l'application exécutera le code pour supprimer un enregistrement dans A, les enfants de la table B seront également supprimés. S'il y a eu un trigger Dolibarr PHP (par exemple apporté par un module externe) sur la suppression de l'enregistrement de B (par exemple pour valider la suppression ou pour exécuter une action complémentaire), la DELETE CASCADE sera exécutée sans avoir le trigger Dolibarr PHP exécuté, manquant la validation ou les actions du déclencheur PHP du module. Donc toutes les règles métiers doivent être implémentées du même côté (côté serveur PHP), c'est la raison pour laquelle les règles métier implémentées sur Database ne sont pas autorisées (même situation que le point suivant sur les triggers Database) | ||
==Utilisation des triggers de base de données / procédures stockées== | |||
L'utilisation des triggers de base de données n'est pas autorisée dans le code de Dolibarr. Vous ne devriez donc rencontrer aucun problème avec ces déclencheurs. | |||
*Les triggers de base de données ne sont pas portables. La compatibilité peut être compromise lors de la mise à jour de votre base de données. | |||
*Les triggers de base de données sont souvent oubliés dans les outils de sauvegarde. | |||
*Les triggers de base de données nécessitent des autorisations spéciales que vous ne possédez peut-être pas (et que vous ne devriez pas posséder) sur une base de données sécurisée classique. | |||
*L'utilisation de triggers de base de données implique également l'inclusion de certaines « règles métier » de votre application dans la base de données, alors que la plupart des autres règles sont gérées par le code lui-même (ce qui peut créer des conflits ou rendre le code impossible à déboguer pas à pas). | |||
*Les triggers de base de données exécutent le code en utilisant le fuseau horaire et la langue par défaut de la base de données, au lieu du fuseau horaire de référence de l'application (qui peut être différent), ce qui génère un décalage dans la base de données. De plus, la langue par défaut de l'application est également déconseillée. | |||
*Il existe de nombreuses raisons pour lesquelles nous déconseillons l'utilisation des triggers de base de données dans vos développements. | |||
L'utilisation de triggers de base de données peut certes vous faire gagner du temps lors du développement, mais constitue une très mauvaise pratique lorsque la qualité, la portabilité, la sécurité et la pérennité sont primordiales. C'est pourquoi elle est interdite, car elle est incompatible avec le haut niveau de qualité de code exigé par l'équipe Dolibarr. Les modules externes utilisant des déclencheurs de base de données peuvent également être refusés sur la plateforme, car ils ne fonctionneront pas pour plus de 50 % des utilisateurs. | |||
==Règles de migration de base== | ==Règles de migration de base== | ||