Nous utilisons actuellement des contraintes de contrôle pour la mise en œuvre des règles de gestion, mais je souhaite savoir si nous devons mettre en œuvre des règles commerciales en SQL ou dans la couche logique des entreprises (C #). J'ai cherché sur le Net et j'ai constaté que les contraintes de vérification sont bonnes à utiliser.
S'il vous plaît laissez-moi savoir si quelqu'un connaît des informations plus détaillées à ce sujet. Une autre chose est que les données peuvent être pompées dans ma base de données à l'aide d'une application mobile et à l'aide d'une application Web.
6 Réponses :
Vous devez vraiment vérifier toujours vos règles d'entreprise dans votre code d'application (dans la couche d'entreprise), mais si jamais possible dans votre base de données.
Pourquoi? Imaginez que quelqu'un parvient à soumettre des données à votre base de données sans utiliser votre application - si vous avez vos chèques seul dans l'application, ces chèques ne sont pas appliqués.
Si vous avez également vos chèques sur la base de données, vous pouvez vous assurer que les données de la base de données se conforment au moins à ces contrôles simples pouvant être formulés dans les contraintes de contrôle SQL.
Utilisez certainement ceux-ci! Vous devez essayer de conserver votre qualité de données aussi élevée que possible - l'ajout d'une intégrité référentielle, de vérifier des contraintes et des contraintes uniques, etc. Dans la base de données vous aide à le faire.
faire
Mais je n'ai plus que cela ne pense pas que cela créera des problèmes de performance et une plus grande quantité de maintenance de maintenance surviennent lorsque vous devez modifier votre BL et construit tous les deux, lorsque la logique change.
Toute performance que cela pourrait coûter est bien investie! Et non - je ne pense pas que cela devrait causer des problèmes de maintenance - toute chance devrait commencer par le niveau de la base de données de toute façon.
comme plus "intelligent" est votre base de données, plus sécurisée sera l'intégrité des données qu'il contient. Donc, oui, je pense que c'est bien et important de le mettre en œuvre.
Cela met en charge de nombreux avantages: vous pouvez vous assurer que vos données seront sécurisées s'il existe plusieurs applications modifiant la modification des données (EX: C # App + Web App + Mobile app ...) et il vous permet de faire moins de travail dans ces applications «secondaires». Si la base de données effectue tout le travail, les applications ne sont qu'un frontend pour la base de données.
Il sera plus facile à venir de migrer les applications, mais sera plus difficile à migrer la base de données. C'est une décision importante.
Vous devez absolument utiliser les contraintes de vérification dans la mesure du possible, mais je ne le ferais pas trop. S'il n'est pas possible d'obtenir des données dans votre base de données sans utiliser vos applications, vous pouvez être en sécurité avec des contraintes de contrôle minimes et une validation de l'entreprise lourde.
Il peut être assez difficile de définir des règles commerciales strictes dans SQL. Collez sur la validation des données dans la base de données et les règles commerciales réelles de votre application.
Aussi, essayez d'organiser votre schéma de manière à ce qu'il est difficile de saisir de mauvaises données avec des clés étrangères et similaires.
Il existe certaines contraintes qui peuvent et doivent être appliquées dans la base de données, par exemple des contraintes de clé étrangère et une unicité. La base de données pourra les appliquer rapidement et efficacement.
Autres contraintes "Business" plus complexes sont mieux appliquées dans la couche logique des entreprises. Des exemples de ceux-ci pourraient être «Le client doit avoir une adresse électronique validée avant d'autoriser un achat». Celles-ci seraient compliquées et onéreuses à appliquer dans la base de données - vous risquez de coder votre système dans SQL, ce qui est une mauvaise idée.
c #. Il est beaucoup plus facile de réutiliser la logique en C # que SQL (dans mon expérience) et de maintenir généralement.
Oui, les contraintes de contrôle sont un outil valide pour les règles d'entreprise.
Mais êtes-vous sûr que vous devez utiliser des contraintes de contrôle ou utiliser une table de support avec une relation de clé étrangère? Si vous vous trouvez en définissant des contraintes de contrôle similaires à divers endroits - la réponse est oui, cela devrait certainement être une table de support.
L'intégrité des données est la clé; Il n'y a pas beaucoup de valeur pour un système qui permettra à une personne de stocker quelque chose qui n'est pas par règlement commercial si la demande est contournée. Il rend également la vie beaucoup plus facile si la logique figure dans la base de données dans la base de données des situations où l'application d'origine est en C # et que les hauts ups ont décidé que le marché a besoin d'une version Java / Ruby / Python / etc.
Vous pouvez facilement faire demi-tour de l'argument. Et si certains des UPS supérieurs ont décidé que la base de données différente est moins chère, plus gentille plus digne de confiance et veut basculer? Les contraintes d'affaires doivent être vérifiées à votre arrière-plan.
@ROBERT: Vous avez mal interprété ma réponse - Je préconise les règles commerciales mises en œuvre dans la base de données, plutôt que le code de la demande.
Je suis en faveur de la vérification des contraintes et de l'intégrité des données - mais je pense qu'une base de données n'est pas le bon endroit pour appliquer les règles de l'entreprise. La logique commerciale appartient à la couche appropriée des solutions logicielles.