2009-02-11 5 views
1

Des règles telles que "Un objet parent aura jusqu'à 2 enfants" pourraient être appliquées dans la base de données en utilisant des déclencheurs. Mais serait-ce une bonne idée de dupliquer la règle si cette règle est déjà appliquée dans la couche domaine.Des règles telles que "Un objet parent aura jusqu'à 2 enfants" seront dupliquées dans la base de données

Dans quels cas la duplication de telles règles est-elle justifiée? Y a-t-il une alternative pour éviter une telle duplication? N'est-ce pas une règle d'intégrité des données?

Merci

Répondre

3

Il est pratiquement impossible de faire cela correctement dans un code qui est en dehors de la base de données. Tout code qui cherche à voir si 2 enregistrements existent déjà et si ce n'est pas le cas permet à un nouvel enregistrement d'être ajouté peut être berné par 2 threads fonctionnant simultanément sur le même parent. À moins que vous ne verrouilliez réellement la table de base de données ou ne sérialisiez en quelque sorte le processus d'ajout d'enfant, ce qui crée un manque réel d'évolutivité. Vous ne mentionnez pas le SGBDR, il est donc difficile de vous donner une solution.

EDIT:

Je suis d'accord avec ceux qui disent que les déclencheurs sont loin d'être propre. Mais ils ne sont pas le seul moyen d'appliquer des règles dans une base de données. C'est pourquoi j'ai dit sans connaître votre SGBDR, il serait impossible de proposer une solution de base de données ou même une qui ne nécessite pas de déclencheur. En outre, vous ne devriez pas avoir besoin d'un déclencheur car votre niveau intermédiaire ne fait jamais de DML, il appelle simplement les procédures de base de données ou les paquets qui encapsulent votre CRUD. Droite?!

0

En général, je garderaient cette logique de la couche de base de données. Cela me ressemble plus à une règle d'affaires, qui devrait vivre dans un niveau d'affaires. Que se passe-t-il si cette règle devait changer? où et dans combien d'endroits voulez-vous le mettre à jour? Typiquement, rien ne devrait accéder à la base de données, sauf par le biais de votre niveau d'entreprise et donc c'est OK de ne pas l'implémenter ailleurs, MAIS le niveau busines. En outre, les déclencheurs sont désordonnés, difficiles à maintenir, et surtout, difficiles à déboguer plus tard.

À mon humble avis de toute façon.

+0

+ 1 pour annuler le vote négatif. Je pense que c'est un point valide – StackUnderflow

0

déclencheurs IMHO sont généralement une « mauvaise chose », mais au-delà, l'application des règles commerciales au niveau des insertions dans les tables de base de données ne me paraît pas une bonne « séparation des préoccupations »

+0

quelqu'un aurait-il voté pour des commentaires? – blank

+0

+ 1 pour annuler le vote négatif. Je pense que c'est un point valide – StackUnderflow

0

J'essayer de rester loin de mettre ce type de «logique de validation d'entreprise» dans votre couche de base de données. Finalement, vous aurez besoin de plus de contrôle et de gestion sur vos données que ce que les déclencheurs fournissent, au fur et à mesure que votre application mûrit.

Si votre application a une couche de gestion, je n'aurais que des relations d'application SQL, et non des règles.

+0

+ 1 pour annuler le vote négatif. Je pense que c'est un point valable – StackUnderflow

2

Je pense que chaque niveau d'un système doit appliquer le nombre maximal de contraintes qu'il est conçu pour gérer. Le reste, vous laissez les autres gérer. Je considère que les contraintes de base de données et les contraintes javascript sont dans la même catégorie; vous faites ce que vous pouvez avec les moyens disponibles tout en restant raisonnablement propre. Les déclencheurs sont loin de ce que je considère raisonnablement propre, donc je laisserais la logique métier gérer cela. Il existe de nombreuses règles d'intégrité des données qui vont bien au-delà de ce que vous pouvez attendre d'une base de données SQL.

1

Cela dépend.

Si toute écriture dans la base de données est effectuée par une application ou un service unique, il est raisonnable d'implémenter ces règles métier dans le niveau métier de l'application/du service. Surtout si vous pensez que les règles peuvent changer à l'avenir. Mais dans de nombreux scénarios du monde réel, en particulier avec les systèmes hérités, vous pouvez avoir plusieurs rédacteurs, et cela peut valoir la complexité supplémentaire d'implémenter de telles règles dans la base de données.

Tout le design est un compromis.

1

Je voudrais que ce soit dans la base de données dans un déclencheur. En effet, les bases de données peuvent être affectées par une interface autre que l'interface graphique et les règles de cette nature qui ne sont pas appliquées au niveau de la base de données entraînent des problèmes d'intégrité des données.

Questions connexes