La vieille question. Où devriez-vous mettre votre logique métier, dans la base de données des procédures stockées ( ou paquets ), ou dans l'application/middle tier? Et surtout, Pourquoi?
Assumer la base de données de l'indépendance n'est pas un objectif.
La maintenabilité de votre code est toujours une grande préoccupation lors de la détermination de l'endroit où les affaires de la logique devrait aller.
Intégré des outils de débogage et de plus en plus puissants IDEs généralement faire l'entretien de niveau intermédiaire code plus facile que le même code dans une procédure stockée. Sauf s'il y a une vraie raison sinon, vous devriez commencer avec la logique métier de votre niveau intermédiaire/de l'application et non dans des procédures stockées.
Cependant, quand vous venez à la présentation et exploitation de bases de données de recherche, les procédures stockées peuvent souvent un meilleur choix. C'est grâce à la puissance de l'agrégation des bases de données/fonctions de filtrage et le fait que vous êtes en gardant le traitement est très proche de la source de données. Mais cela peut ne pas être ce que la plupart considèrent classique de la logique métier de toute façon.
Pour des cas très simples que vous pouvez mettre votre logique métier dans les procédures stockées. Généralement, même les cas les plus simples ont tendance à se compliquer au fil du temps. Voici les raisons pour lesquelles je ne mets pas de logique métier dans la base de données:
Mettre de la logique métier dans la base de données étroitement les couples à la mise en œuvre technique de la base de données. La modification d'une table vous fera changer beaucoup de procédures stockées, provoquant de nouveau beaucoup de bugs et de test supplémentaire.
Généralement, l'INTERFACE utilisateur repose sur une logique d'entreprise pour des choses comme la validation. Mettre ces choses dans la base de données entraîne un couplage étroit entre la base de données et l'INTERFACE utilisateur ou en cas différents doublons la logique de validation entre les deux.
Il va être dur d'avoir de multiples applications fonctionnent sur la même base de données. Les changements pour une aplication faire de pause. Cela peut rapidement se transformer en un entretien cauchemar. Donc, il n'a pas vraiment d'échelle.
Plus pratiquement SQL n'est pas un bon langage pour implémenter la logique métier d'une manière compréhensible. SQL est idéal pour les définir en fonction des opérations, mais il manque des constructions de programmation "dans le grand" il est difficile de maintenir de grandes quantités de procédures stockées. Moderne OO langues sont mieux adaptés et plus souple pour ce.
Cela ne signifie pas que vous ne pouvez pas utiliser stockées proc et les points de vue. Je pense que c'est parfois une bonne idée de mettre une couche supplémentaire de procédures stockées et de points de vue entre les tables et les demande(s) de dissocier les deux. De cette façon, vous pouvez changer la disposition de la base de données sans changer d'interface externe vous permettant de refactoriser la base de données de manière indépendante.
C'est vraiment à vous, aussi longtemps que vous êtes cohérent.
Une bonne raison de le mettre dans votre couche de base de données: si vous êtes assez sûr que vos clients ne pourront jamais changer leur base de données back-end.
Une bonne raison de le mettre dans la couche de l'application: si vous ciblez persistance de multiples technologies pour votre application.
Vous devez également prendre en compte les compétences de base. Sont vos développeurs principalement de l'application de la couche de développeurs, ou sont-ils principalement DBA-types?
Bien qu'il existe certainement des avantages à avoir de la logique métier de l'application de la couche, je tiens à souligner que les langages/frameworks semblent changer plus fréquemment, puis les bases de données.
Certains des systèmes que je soutiens, est passé par la suite de l'Isu dans les 10 à 15 dernières années: Oracle Forms/Visual Basic/Perl CGI/ ASP/Servlet Java. La seule chose qui ne change pas - la base de données relationnelle et les procédures stockées.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
