J'ai appliqué des règles commerciales dans mes deux niveaux d'application (modèles) et mon niveau de base de données (procédures stockées qui soulèvent des erreurs).
Je fais dupliquer mes validations dans les deux endroits pour quelques raisons:
Quel est le bon équilibre?
3 Réponses :
Vous devez faire respecter le niveau de données pour assurer l'intégrité des données. C'est votre dernière ligne de défense et c'est l'emploi DBS, pour aider à appliquer sa vision du monde des données.
Cela dit, jetant des données indésirables contre la DB pour validation est une technique grossière. Typiquement, les erreurs sont conçues pour être lisibles pour l'homme plutôt que pour la machine lisible, de sorte son inefficace pour le programme de traitement de l'erreur de la DB et de faire des têtes ou des queues.
Les procédures stockées sont une question différente. De retour dans la journée, les procédures stockées ont été le moyen de gérer les règles d'entreprise sur les niveaux de données, etc.
Mais aujourd'hui, avec les environnements de serveurs d'applications modernes, ils sont devenus un lieu de retour un meilleur endroit pour mettre cette logique. Ils offrent plusieurs façons d'accéder et d'exposer les données (Web, services Web, protocoles distants, API, etc.). En outre, si vos règles sont lourdes lourdes (sans doute la plupart ne sont pas), il est plus facile d'élaborer des serveurs d'applications que des serveurs DB.
La grande gamme de fonctionnalités des serveurs d'applications lui donne une flexibilité au-delà de ce que les serveurs de base de données peuvent faire, et donc une grande partie de ce qui a été poussé une fois dans le DBS est retiré avec les serveurs de DB étant relégué "muet persistance ".
Cela dit, il existe certainement des avantages de performance à l'aide de Procs stockés et tels que, mais maintenant, c'est une chose de réglage où la question devient "vaut-t-elle la peine de perdre la capacité du serveur d'applications pour le gain que nous obtenons en la mettant dans le serveur DB" .
et par App Server, je ne parle pas simplement Java, mais .net et même PHP, etc.
Quelle est la différence entre l'application de la logique commerciale et l'intégrité des données? Supposons que j'ai une règle d'entreprise qui dit au plus 3 personnes puisse être affectée à un superviseur. Quand je vais à insérer la personne n ° 4, est-ce que c'est échoué parce que c'est une erreur d'intégrité de données d'avoir> 3 personnes par superviseur ou s'agit-il d'une violation des règles d'entreprise? Sans verrouillage du record de superviseur avant de vérifier qu'il existe au plus 2 personnes sous un superviseur lors d'une insertion, comment le code de l'application peut-il être sûr de 100% que cette règle ne sera pas cassée?
@RednerLn - Taux de changement. Les règles d'intégrité de la base de données sont des mesures susceptibles d'être assumées pour être vraies pour beaucoup plus longtemps que les règles commerciales. Votre exemple de personnes à un superviseur, j'aurais du mal à justifier de faire une contrainte de base de données, si je faisais, il faudrait être basé sur les données (UDF basée sur un paramètre de configuration). Et si la règle change, il faut poser la question de savoir quoi faire sur les données qui enfreint ce principe. Généralement, vous souhaitez que les règles de base de données ne soient détendues, non serrées ou modifiées qualitativement.
@RednerLn - dans des situations multi-modales, vous voulez que les gens puissent frapper votre couche d'accès à la base de données (vues, peut-être) avec leurs outils BI ou quoi que ce soit et sachez que leurs hypothèses sont valides, que la base de données a la cohésion et l'intégrité à son périmètre .
Votre logique d'entreprise peut s'asseoir dans l'un ou l'autre endroit, mais ne devrait pas être dans les deux. La logique ne doit pas être dupliquée car il est facile de faire une erreur en essayant de garder les deux sous synchronisation. Si vous le mettez dans le modèle, vous souhaitez que tous les données ont accès à vos modèles, y compris les mises à jour de lots.
Il y aura des compromis pour la mettre dans la base de données vs les modèles d'application (voici quelques-uns des sommets de ma tête):
Si la règle doit être appliquée à tout moment, peu importe où les données sont venues ou comment elles ont été mises à jour, la base de données est là où elle doit être. Notez que les bases de données sont affectées par des interrogations directes pour apporter des modifications qui affectent de nombreux enregistrements ou de faire quelque chose que l'application ne ferait normalement pas. Ce sont des choses comme la réparation d'un groupe d'enregistrements lorsqu'un client est acheté par un autre client et qu'ils veulent changer toutes les données historiques, l'application de nouveaux taux de taxe aux commandes non encore traitées, la fixation d'une mauvaise inscription de données. Ils sont également affectés parfois par d'autres applications qui n'utilisent pas votre couche de données. Ils peuvent également être affectés par les importations via des programmes ETL qui ne peuvent également pas utiliser votre couche de données. Donc, si la règle doit être suivie dans tous les cas, elle doit être dans la base de données.
Si la règle n'est que pour des cas spéciaux concernant la manière dont cette page d'entrée particulière fonctionne, elle doit être dans l'application. Donc, si un responsable des ventes n'a que des éléments spécifiques qu'il peut faire à partir de son interface utilisateur, ces éléments peuvent être spécifiés dans l'application.
quelque chose, il est utile de faire dans les deux endroits. Par exemple, il est idiot de permettre à un utilisateur de mettre un non-date dans une zone d'entrée qui se rapportera à un champ de date. Le type de données dans la base de données doit toujours être un type de données DateTime, mais il est préférable de vérifier certaines de ces choses avant d'envoyer.