Бизнес-логика в SQL Server 2008

Если есть какие-то администраторы баз данных, я делаю довольно большую часть программного обеспечения, и одна из самых больших проблем в настоящее время заключается в том, где разместить бизнес-логику. Хотя хранимые процедуры было бы легче исправить на лету, требования к обработке, вероятно, сильно замедлили бы работу БД. Я также не хочу, чтобы вся бизнес-логика обрабатывалась приложением, потому что я хочу, чтобы оно было «самоподдерживающимся объектом», для работы которого не требуется интерфейс пользователя.

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

Идеи? Да? Нет?

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


sql sql-server business-logic
person instantmusic    schedule 09.08.2010    source источник
comment
Я согласен с вашей архитектурой. Если вы не хотите управлять бизнес-логикой на уровне базы данных или приложения, вам определенно подойдет средний уровень обслуживания.   -  person kbrimington    schedule 09.08.2010

Ответы (5)


arrow_upward
3
arrow_downward

Что вы имеете в виду под «бизнес-логикой»?

Я видел случаи, когда агрегации и другие операции на основе наборов выполнялись в клиентском коде, а также ужасные операции RBAR в SQL, которые должны быть где-то еще.

SQL - это один из инструментов, который имеет свое место: если вы работаете с большими наборами данных, СОЕДИНЕНИЯМИ, агрегатами и т. Д., Тогда SQL - то место, где это можно сделать. Все остальное - рабское подчинение идеалу SOA.

Мой подход состоит в том, чтобы рассмотреть, что делает хранимый процесс или SQL: является ли он частью среднего уровня, чтобы избежать операций на основе наборов в процедурном коде, или он ниже, чем чистая целостность / постоянство данных?

Если ваша бизнес-логика настроена на 100%, то вам, возможно, не нужен средний уровень (редактировать: на основе клиентского кода), если только он не очень тонкий.

person gbn    schedule 09.08.2010
comment
Ах, чтобы предоставить немного больше информации. Я бы хотел, чтобы база данных просто поддерживала логику данных. Например, если это поле может быть или не может быть нулевым, оно применит указанное ограничение. Если удаление этой записи должно происходить каскадно с дочерними записями, он справится с этим. Однако (для неприятного примера), если у меня есть просроченный платеж, я могу записать его просрочку. Это будет делать приложение-посредник. Если в моем инвентаре есть несоответствие, я бы взял его за среднюю и основную ручку. Предполагая, что вы имеете в виду именно это. - person instantmusic; 09.08.2010
comment
@instantmusic: да. Ответ Рэнди выражает это лучше, чем этот. Просроченный платеж - это просто платеж с другим значением в поле статуса (или чем-то еще), который не может и не должен определяться SQL. Однако вычисление СУММЫ платежей для определенного статуса будет выглядеть следующим образом: клиент отправляет, по каким статусам следует суммировать. - person gbn; 09.08.2010
comment
Верно, верно, чтобы я мог предоставить только необходимые хранимые процедуры для предоставления информации о состоянии данных. то есть sp_GetCustomerDelinquentTotal (Customer) просто вернет общую сумму $$$, которую один клиент просрочил. - person instantmusic; 09.08.2010
comment
@instantmusic: я бы больше сказал sp_GetCustomerTotal (Customer, Status), где Status может быть просроченным, списанным, просроченным и т. д. Таким образом, WHERE и SUM основаны на SQL, но только клиент понимает статус (просто значение в WHERE to БД). Таким образом, одна общая хранимая процедура может иметь дело со многими состояниями. Знание / значение статуса - бизнес / средний, но совокупность - SQL / набор. - person gbn; 09.08.2010
comment
Отлично, огромное спасибо за вашу помощь (и всем, кто ответил по этому поводу). Думаю, теперь я знаю, с чего начать. В общем, я еще немного почитаю, и к концу дня я должен знать достаточно, чтобы принять обоснованное решение. Еще раз спасибо!!! - person instantmusic; 09.08.2010
comment
@instantmusic: Спасибо. И последнее: sp_GetCustomerTotal можно рассматривать как средний уровень, который живет в БД, потому что это правильный инструмент для фильтрации и агрегирования большого количества данных ... - person gbn; 09.08.2010

arrow_upward
4
arrow_downward

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

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

Затем решите, подходит ли клиент, сервер среднего уровня или база данных для какой-либо дополнительной бизнес-логики.

person Randy    schedule 09.08.2010
comment
Именно это я имел в виду для роли базы данных. Я добавил больше информации в комментарии gbn, которые касались именно этого. Тем не менее, спасибо за разъяснения, приятно знать, что я на правильном пути. - person instantmusic; 09.08.2010

arrow_upward
2
arrow_downward

На протяжении многих лет я видел, как клиентские приложения приходят и уходят, но база данных все еще существует.

Поэтому в настоящее время я использую хранимые процедуры для большей части бизнес-логики. Три больших преимущества:

  • Развертывание исправления ошибок происходит мгновенно, без простоев
  • По умолчанию многопользовательский
  • Намного меньше сантехнического кода (без уровня доступа к данным)
person Andomar    schedule 09.08.2010

arrow_upward
1
arrow_downward

Иметь всю бизнес-логику на стороне сервера - это нормально.
Не иметь ее на стороне сервера - тоже нормально.

Фактически, решать вам.
Если хранимая процедура имеет тенденцию выглядеть не в стиле sql, вы можете создать хранимая процедура CLR.

Вот аналогичный вопрос.

person GSerg    schedule 09.08.2010

arrow_upward
0
arrow_downward

Я настоятельно рекомендую традиционный n-слойный подход, при котором у вас есть как минимум уровень пользовательского интерфейса, бизнес-уровень (например, сборка C # или эквивалент Java) и доступ к данным. См .: http://en.wikipedia.org/wiki/Multitier_architecture.

Я работал в компании, где вся бизнес-логика была в процессах, а затраты на обслуживание намного выше, чем они должны были быть, это ограничивало нас конкретной версией sql-сервера, она не масштабировалась и т. Д. Короче говоря, если только ваше приложение - это простая вещь, которую можно выбросить, я бы не стал помещать бизнес-логику в базу данных.

person Andy    schedule 09.08.2010
comment
рабское подчинение идеалу SOA.? Вы имеете в виду, что вы выполнили всю свою логику, основанную на наборах, на среднем уровне? - person gbn; 09.08.2010
comment
Очень мало бизнес-логики, если таковая вообще существует, работает с большими наборами данных. По крайней мере, таков мой опыт. Я согласен с тем, чтобы позволить базам данных делать то, что у них лучше всего, но если вы пишете процедуры с большим количеством операторов if, выполняющих проверки данных или других ветвлений, эта логика более удобна в обслуживании, если ее переместить на бизнес-уровень. Если вы используете SSMS и добавляете сборку C # в свою базу данных, вам следует хорошо подумать, зачем вы это делаете. - person Andy; 10.08.2010