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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

SQL - это один инструмент, у которого есть свое место: если вы работаете с большими наборами данных, JOIN, объединениями и т. д., то SQL - место, где это можно сделать.Все остальное - рабское подчинение идеалу SOA.

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

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

Answer 3

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

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

• Развертывание исправления ошибок занимает мгновенное время без простоев
• Многопользовательский по умолчанию
• Гораздо меньше кода (без слоя доступа к данным)

Answer 4

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

На самом деле, это зависит от вас.
Если хранимая процедура имеет тенденцию выглядеть не sql-ish, вы можете сделать CLR хранимую процедуру .

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

Answer 5

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

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