Ai-je vraiment besoin de déclencheurs pour la base de données relationnelle, par exemple, PostgreSQL?
Je sais que les déclencheurs peuvent être utilisés pour valider les données stockées pour que la base de données soit cohérente. Cependant, pourquoi ne pas exécuter la validation des données sur le côté de l'application avant de les stocker dans la base de données?
Par exemple, nous stockons des clients et nous souhaitons effectuer une certaine validation qui ne peut pas être facilement effectuée sur le niveau DDL. https://severalnines.com/blog/postgresql-Triggers-and-SttorReocer-Basics
Un autre exemple est l'audit.
Mettre à jour
Comment les déclencheurs et la transaction de base de données fonctionnent ensemble. Par exemple, si je voudrais effectuer une validation des données insérées. Cela se fait à l'intérieur d'une transaction. Que se passe-t-il plus tôt: la transaction est engagée ou la gâchette est exécutée?
Cela dépend du type de système d'application que vous construisez:
si vous créez un système centrée sur l'application qui contient une seule application principale, avec une base de données dédiée spécifiquement pour cette application, et idéalement une équipe responsable de l'évolution de l'application et de la base de données côte à côte, vous pouvez conserver toute la logique de validation et également audit. logique à l'intérieur de l'application.
Le principal avantage est que vous n'avez pas à distribuer la logique commerciale entre application et dB, la maintenance et l'évolution du système deviennent souvent plus faciles. En tant que bonus, vous ne liez pas trop l'application sur un type spécifique de fournisseur de SGBD ou de DBMS. Cette approche est évidemment requise si votre demande souhaite pouvoir utiliser un système de DB léger qui ne fournit pas de déclencheurs.
Si, toutefois, vous créez un système dans lequel de nombreuses applications différentes partagent une base de données commune et ne peuvent pas envisager à l'avance quelles applications l'écriront à l'avenir, ou quelles équipes développeront des applications de remplissage de données dans la DB à l'avenir, puis est préférable que votre base de données sera responsable de la garantie autant de cohérence des données que possible. Et c'est là que les déclencheurs deviennent vraiment utiles. Dans les systèmes plus importants, les contraintes de référence ne suffisent souvent pas pour cela, mais un déclencheur qui appelle une procédure stockée peut mettre en œuvre presque tout type de validation dont vous avez besoin.
Une autre raison d'utiliser des déclencheurs peut être une performance: dans des modèles de données complexes, il n'est pas rare de rencontrer des règles de cohérence complexes nécessitant de nombreuses données supplémentaires qui ne font pas partie de l'ensemble de travail actuel disponible sur l'application client. Transférer toutes ces données sur le réseau d'abord pour que la validation possible au client peut avoir un impact de performance notable.
Voir aussi cet ancien poste SE: Application logique VS DB déclenchers pour le nettoyage de la base de données
Donc, décidez pour vous quel type de système vous construisez, vous pouvez alors faire une décision fondée si des déclencheurs sont le bon outil pour votre cas ou non.
Je pense que la question concerne la responsabilité de la qualité des données.
La réponse dépend de la façon dont vous voyez le système.
Si vous voyez la base de données en tant que service indépendant, distinct et autonome distinct de l'application, la base de données est chargée de garantir la cohérence et la qualité des données qu'il contient. Essentiellement parce que cette base de données pourrait être utilisée par une autre application, elle ne peut donc pas compter sur cette deuxième application ayant les mêmes comportements de cohérence et de qualité. Dans ces circonstances, la base de données doit être conçue pour exposer une API et un comportement autonome. Dans cet affichage, il existe au moins deux applications, l'une d'entre elles est la base de données et l'autre est l'application à l'aide de celle-ci.
À l'inverse, la base de données pourrait être considérée comme une forme compliquée de fichier sous le contrôle direct et total de l'application. Dans ce sens, la base de données évolue d'être un outil pur sérialisation et de navigation de documents. Il peut fournir des comportements avancés pour supporter la requête et la maintenance de documents (comme JSON ou les outils XML), mais à nouveau, il n'est pas nécessaire (comme la plupart des flux de fichiers). Dans ce cas, il est purement responsable des programmes de maintenir le format et le contenu corrects dans le fichier. Dans ce point de vue, il y a une application.
Dans les deux points de vue, la question suivante est de savoir comment prendre en charge l'utilisation de la base de données comme un fichier fantaisie ou un service séparé. Vous pourriez y parvenir par:
- utilisation des outils que la plate-forme de base de données fournit sous la forme de tables/vues/procédures stockées/déclencheurs/etc ...
- emballage de la base de données elle-même dans un service que tous les clients doivent utiliser afin d'accéder à la base de données.
- enveloppez la base de données dans une bibliothèque qui doit être utilisée par tous les clients afin d'accéder aux données.
Chacun vient avec ses propres avantages/contre et dépendra des contraintes architecturales de l'environnement que le système fonctionne dans.
Indépendamment de quelle vue vous prenez, cela paie toujours pour valider les données à des limites.
- Validez les champs sur une interface utilisateur qu'un utilisateur entre
- Validez la demande réseau/API avant qu'il ne quitte le client
- Validez la demande réseau/API sur le serveur avant de faire quoi que ce soit
- Valider les données transmises dans des règles d'entreprise
- Valider les données avant d'être persisté
- Valider les données après avoir été récupérée de la persistance
- donc, et ainsi de suite
Quelle validation est justifiée à chaque frontière dépend de la manière dont il est risqué de ne pas la valider.
- multiplier deux nombres ensemble?
- vous obtenez le mauvais numéro est-ce un problème?
- invoquant une procédure sur un emplacement de mémoire donné?
- Qu'est-ce que l'emplacement de la mémoire?
- Que se passe-t-il si l'objet n'existe pas, ou est dans un mauvais état?
- en utilisant une regex sur une chaîne contenant du kanji? [.____]
- Le module de regex peut-il gérer unicode?
- La regex peut-elle gérer unicode?
Non, vous ne devez jamais utiliser de déclencheurs pour faire de la validation.
La base de données n'est responsable que de sa propre intégrité. Toute validation confrontée à l'utilisateur doit être effectuée par votre application.
Les bases de données effectuent trois niveaux de validation pour l'intégrité. Le premier est la validation du niveau de champ. Un champ peut être nécessaire, s'il n'y a pas de valeur (null), c'est une erreur. Cela peut également être une contrainte de contrôle; Un domaine a un nombre énuméré de valeurs.
Deuxièmement, il y a des relations entre les tables. Dans une table, vous stockez une ou plusieurs clés étrangères, relatives à cette table à d'autres tables et nécessitant les valeurs d'être des clés valides pour "autre table". Pensez à une base de données d'adresse, où nous soutenons les adresses de différents pays. Une clé de pays dans une adresse doit indiquer un pays connu. Si les données (par exemple, un code postal) est valide, ce n'est pas une préoccupation de cette vérification d'intégrité.
Troisièmement et les plus compliqués sont des déclencheurs. En règle générale, celles-ci devraient aborder (le jeu de mots non destiné) concernent des règles d'intégrité qui sont conditionnelles. Pour revenir à l'adresse de l'adresse: si un pays n'a pas de codes postaux, ce serait un problème si un pays de cette liste aurait un code postal. Donc, la vérification serait la suivante: Si ce pays n'a pas de codes postaux, le champ Code postal doit être null.
La validation est la préoccupation de la demande. Le fait qu'un code postal allemand consiste en seulement des chiffres est un chèque que l'application doit apporter, pas la base de données. La ligne est une mince, vous pourriez peut-être avoir besoin de penser/discuter dans certains cas si quelque chose doit être dans une gâchette (protéger l'intégrité de votre base de données) ou dans l'application (Validation de l'utilisateur confronté).
L'audit est un exemple classique d'utilisation efficacement des déclencheurs. J'ai trouvé des erreurs faites par le testeur (déplacement d'un client d'un niveau de service à un autre) grâce à une table d'audit mise en œuvre par des déclencheurs. Je recommande vivement d'utiliser des déclencheurs pour l'audit.
Validation pourrait être fait au niveau de l'extrémité avant, mais j'ai vu des erreurs étranges dans la base de données que j'ai manipulée (personnes nées dans 3000, etc.), et que certaines d'entre elles, je me suis fait Je recommande fortement d'avoir une couche supplémentaire de validation dans la base de données, au cas où. Bien entendu, ces types d'erreurs pourraient être évités avec les contraintes de chèques et plusieurs fois, elles sont plus efficaces (dans MS SQL, ils sont la méthode préférée; toujours vérifier la documentation).
Parce que la question est de savoir si nous avons vraiment besoin de déclencheurs pour des bases de données relationnelles ici, voici quelques autres cas d'utilisation où utiliser des déclencheurs:
- Pour l'audit comme décrit dans les autres réponses.
- Audit dans le sens plus large: Si une entrée de base de données est modifiée, un déclencheur peut enregistrer l'événement pour le post-traitement asydroneux, par ex. exportations nocturnes vers une autre application.
- Déclencheurs pour vues: Les déclencheurs peuvent être définis
instead of. Avec cette moyenne, on peut insérer, mettre à jour et supprimer des entrées d'une vue. Les déclencheurs peuvent diffuser ces actions sur plusieurs tables. C'est un moyen de faire une vue restreinte disponible sans exposer les détails des tables sous-jacentes. - Pour enregistrer explicitement les tour de base de données: supposez A N: M Relations entre Table A et B et une table intermédiaire R. Vous pouvez définir des contraintes de clé étrangère de R à A à A à A à A aussi bien que B spécifiant que l'entrée dans R doit être supprimée si son L'entrée correspondante en B est supprimée. Toutefois, la logique des entreprises nécessite parfois que les entrées d'une indemnité doivent avoir au moins une relation avec une entrée de B. Dans ce cas, un déclenchement de la suppression de R peut aider à appliquer cette logique: si pour une entrée dans une dernière entrée de R Est supprimé alors que la gâchette peut supprimer A. dans la vue centrée sur l'application au moins deux tours de tour. Ceci est un exemple de validation. D'autres exemples sont concevables: à côté des cas d'utilisation (1), (2), et (3) où les déclencheurs permettent d'enregistrer des tours de tour autour du cas où un utilisateur est inséré dans une table utilisateur et un ensemble de valeurs par défaut dans une table de préférence est de être généré.
- Trust: Parfois, les entrées de base de données modifient les entrées de la ligne de commande n'utilisant pas votre application. Les administrateurs travaillent soigneusement et savent ce qu'ils font. Cependant, parfois ils pourraient avoir tort. Si la cohérence est essentielle, un déclencheur est leur ceinture de sécurité.
En tant que logique commerciale de l'inconvénient, la logique est distribuée entre les couches et il s'agit d'un inconvénient majeur pour la maintenance. Comme un autre auteur écrit, il s'agit d'une limite mince entre l'application et la base de données et le choix n'est pas toujours clair. Mon opinion personnelle est que les déclencheurs placent un fardeau sur les développeurs. Ils peuvent gagner du temps au développement. Ils améliorent définitivement l'expiration de l'utilisateur car ils stimulent les performances sur des connexions réseau lentes.