La logique métier dans la procédure stockée - toujours confus

Question

J'ai lu beaucoup de articles pour savoir pourquoi nous ne devrions pas avoir de logique métier à plusieurs endroits, mais essayez de le conserver en code BLL. Je comprends le point de la maintenance facile, et une meilleure compréhension de ce que le code fait.

Cependant, je n'ai jamais trouvé d'explication que devrions-nous faire dans les cas où l'application (répétition) de certaines règles métier à la procédure stockée réduirait considérablement le transfert de données de la base de données à l'application cliente? Par exemple, je travaille actuellement sur une présentation de données statis- tiques sur une période de temps plus longue. Actuellement, toutes les règles/règles métier sont dans la couche Logique d'entreprise (dll). Un utilisateur a une option pour afficher certains résultats au niveau du mois pour une année. Cela signifierait que, si je ne dois pas utiliser de règles métier dans une procédure stockée, je devrais renvoyer environ 1 000 000 enregistrements, puis appliquer des règles métier à ces enregistrements du côté client. Cependant, si je suis d'appliquer des règles d'affaires à la procédure stockée, il réduirait le nombre d'enregistrements renvoyés à 12.

ressemblerait à quelque chose comme un exemple d'application des règles métier ceci:

AVG(CASE WHEN Field1 IS NULL 
       THEN CASE WHEN c.Field2 = 1 
       THEN (cap1.Field3/cap1.Field4) * 60 
       ELSE CASE 
..... etc 

il n'est pas une logique simple, mais complexe. Et puisque ce type de logique pourrait répéter dans de nombreuses procédures stockées différentes, ce serait un candidat pour une fonction distincte dans la base de données, pour éviter le code répétitif.

Alors, quelle est la méthode recommandée ici? Et pourquoi?

Answer 1

Peut-être que vous pouvez toujours avoir une logique métier à laquelle il appartient et classer ces éléments comme plus de "calculs"? De toute façon, vous avez une raison impérieuse de faire les calculs dans la couche de base de données lorsque vous êtes à un million de lignes et plus. Donc je garderais le calcul dans les fonctions. Donc, dans votre exemple une fonction réutilisable serait utilisé comme:

SELECT AVG(dbo.fnFieldsEvaluate(Field1, Field2, Field3, Field5)) as FieldAvgs, 
... 

Ou s'il est utilisé beaucoup, assez simple et ne dépend que des colonnes en une seule rangée, une colonne calculée dans le tableau serait plus pratique .

CREATE TABLE dbo.Products 
    (Field1 ...., 
    Field2 ...., 
    RowEvaluatesTo AS CASE WHEN Field1 IS NULL 
       THEN CASE WHEN Field2 = 1 
       THEN(Field3/Field4) * 60 
       ELSE CASE ... 

Votre fonction dbo.fnFieldsEvaluat (ou une colonne calculée), fourniraient le seul endroit où que des vies de calcul.