Бизнес-логика в хранимой процедуре - все еще запутана

Я прочитал много статьи о том, почему мы не должны иметь бизнес-логику в нескольких местах, но постараемся сохранить ее в коде BLL. Я понимаю смысл простого обслуживания и более четкого понимания того, что делает код.

Однако я так и не нашел объяснений, что нам делать в случаях, когда применение (повторение) некоторых бизнес-правил к хранимой процедуре значительно сократит передачу данных из базы данных в клиентское приложение?

Например, в настоящее время я работаю над представлением некоторых статистических данных за более длительный период времени. В настоящее время вся бизнес-логика / правила находятся на уровне бизнес-логики (dll). У пользователя есть возможность отображать некоторые результаты на уровне месяца за один год. Это будет означать, что, если я не буду использовать бизнес-правила в хранимой процедуре, мне нужно будет вернуть около 1 000 000 записей, а затем применить бизнес-правила к этим записям на стороне клиента. Однако, если я буду применять бизнес-правила к хранимой процедуре, это уменьшит количество возвращаемых записей до 12.

Пример применения бизнес-правил будет выглядеть примерно так:

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

так что это не простая логика, а сложная. А поскольку подобная логика может повторяться во многих различных хранимых процедурах, это может быть кандидатом для отдельной функции в базе данных, чтобы избежать повторяющегося кода.

Итак, какой здесь рекомендуемый способ? И почему?


stored-procedures business-logic-layer
person Goran    schedule 21.05.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Может быть, у вас все еще есть бизнес-логика, которой она принадлежит, и классифицировать эти вещи как «вычисления»?

В любом случае у вас есть веская причина выполнять вычисления на уровне базы данных, когда у вас миллион с лишним строк. Поэтому я бы сохранил расчет в функциях. Итак, в вашем примере будет использоваться функция многократного использования, например:

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

Или, если он используется часто, достаточно просто и зависит только от столбцов в одной строке, вычисляемый столбец в таблице был бы более удобным.

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

Ваша функция dbo.fnFieldsEvaluat (или вычисляемый столбец) предоставит единственное место, где живет это вычисление.

person JBrooks    schedule 21.05.2014