Supposons qu'une application dispose de toutes les règles d'entreprise nécessaires dans la couche Modèle / Présentation et qu'elles fonctionnent bien. Ma question est celle de savoir si des règles commerciales redondantes (c'est-à-dire une étendue de deux dates ne peuvent se chevaucher à aucune autre spans existante ) doivent être utilisées dans un référentiel comme SQL Server.
est-il nécessaire / bénéfique d'ajouter une contrainte dans SQL Server qui applique cette règle? D'une part, il empêche toute personne (y compris les DBA) de casser inadvertance les règles commerciales lorsqu'elles contourneront la demande. De plus, nous avons déjà des formes de règles commerciales dans le référentiel via des clés primaires et étrangères. D'autre part, les règles dupliquées nécessitent du temps supplémentaire pour développer et entretenir.
Cette question couvre de nombreuses technologies différentes, donc j'ai intentionnellement gardé les balises génériques.
5 Réponses :
dépend de votre application - Gardez la logique dans le code de l'application si elle est destinée à être dB agnostique. Sinon, les règles métiers conviennent mieux dans la base de données.
Vous l'avez dit vous-même ... ce qui applique les règles de l'entreprise sur la porte arrière (c'est-à-dire les données de la DBA Poker). Si vous craignez que cela se produise, payez le prix. Sinon, laissez-le, alors les règles appliquées ailleurs ne seront pas redondantes.
Vous trouverez généralement très difficile de maintenir des règles d'entreprise dans plusieurs endroits à la main.
J'ai fait un bon usage de la génération de code sur certains projets afin de générer des types de règles des modèles d'exigence. Par exemple, je pourrais avoir l'exigence "Le prénom ne doit pas dépasser 50 caractères". Je modélise cette exigence d'UML de manière structurée, puis générer un code d'interface utilisateur pour plafonner l'entrée à 50 caractères, la logique commerciale pour appliquer cette même limite (ne faites jamais confiance à l'interface utilisateur!), Et fichier de mappage DDL / ORM pour spécifier la largeur de la colonne dans le dB.
La même idée pourrait être étendue à modéliser des règles plus complexes et générer un code d'application approprié dans chaque couche de l'application.
+1 pour «Très difficile de maintenir les règles d'entreprise dans plusieurs endroits à la main». C'est si souvent oublié!
Il est suffisamment difficile de conserver l'interface utilisateur et des entreprises de synchronisation pour un grand projet, sans parler des règles dans une troisième place.
Si vous vous souciez de vos données, vous mettrez les règles requises là-bas de préférence à partout ailleurs. Les données sont affectées de nombreux endroits au-delà des applications. Mettre des règles uniquement dans la couche d'entreprise est à court et conduit à de graves problèmes d'intégrité de données à Atat peut être horrible pour essayer de réparer. Les règles concernant les données appartiennent à la base de données.
Êtes-vous en train de dire que les règles concernant les données appartiennent à seulement dans la base de données ou qu'ils devraient être dans les couches d'entreprise et de données? Si le plus tard, quelle approche avez-vous l'habitude de les conserver en synchronisation sur de grands projets?
S'ils sont nécessaires, je les ai mis dans la base de données en premier. Il est plus critique que ces contraintes entrent dans la base de données que l'avant. Je laisse les équipes d'application savoir si les contraintes ont changé, elles peuvent donc ajuster si besoin d'être. Habituellement, ces projets auront une personne de base de données et un programmeur d'application attribué, nous gardons donc les choses coordonnées. Si les règles peuvent très en fonction de ce que l'utilisateur a fait, ils appartiennent à la couche d'entreprise. Ceci est des données qui ne sont pas souvent entrées par les importations ou les requêtes publicitaires et il convient donc à la couche d'entreprise.
Exactement le type de retour que je recherche - merci Hlgem (et autres).
règle d'entreprise ou règle d'intégrité des données?
Mon expérience (principalement grande entreprise, nous ne parlons pas de logiciels ou de magasin de loisirs ici) est que votre base de données survivra à l'application. Et éventuellement avoir d'autres applications qui y parlent. Et quelqu'un, quelque part allongera la base de données s'il n'a pas de règles (de quelque nature que ce soit) en place.