В чем преимущество использования множества сложных хранимых процедур

Question

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

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

Я могу предположить, что может быть 2 преимущества:

1. Изменить бизнес-логику без компиляции. Но SP гораздо сложнее поддерживать и тестировать, чем код Java / C #.
2. Уменьшить количество подключений к БД. Однако в общем случае узким местом базы данных является жесткий диск, а не сетевой ввод.

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

Answer 1

В основном, выгода # 2 в вашем списке проблем - если вы выполняете много обработки в своей базе данных, то она обрабатывается там и не зависит от приложения, обращающегося к базе данных.

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

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

Это основная причина, по которой хранятся процы вместо BLL на основе кода.

Кроме того, используя Views для чтения и Stored Procs для обновления / вставки, администратор базы данных может удалить любые прямые разрешения для базовых таблиц. Вашим пользователям больше не нужно иметь все права на таблицы, и, следовательно, ваши данные в ваших таблицах лучше защищены от случайных или злонамеренных изменений.

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

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

Answer 2

Не бойся БД.

Давайте также не будем путать логику business с data logic, которое по праву занимает свое место в БД.

Хорошие разработчики систем будут использовать гибкую бизнес-логику через логику данных, то есть определения абстрактных бизнес-правил, которые могут быть обусловлены (не) существованием или атрибутами атрибутов строк данных.

Только FYI, наиболее успешные и масштабируемые "корпоративные / коммерческие" программные реализации, с которыми я работал, переводят все проекционные запросы в представления и все управление данными либо в процедуры БД, либо в триггеры для поэтапных таблиц.

Answer 3

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

Получение определенных очков:

1. Транзакции являются единицами работы. я не понимаю, почему реализация транзакции в хранимых процедурах следует изменить их гранулярность.
2. Бизнес-логика, которая применяется к данные принадлежат данным: что максимизирует сплоченность.
3. Трудно написать хороший SQL и учиться думать в наборах. Следовательно может показаться, что база данных узкое место На самом деле, если мы предпринимая много работы, которая относится к данным базы данных наверное, самое эффективное место для делаем.

Что касается обслуживания: если мы знакомы с PL / SQL, T-SQL и т. Д., Обслуживание проще, чем может показаться извне. Но я допускаю, что поддержка инструментов для таких вещей, как рефакторинг, отстает от поддержки других языков.

Answer 4

Сеть между appServer и sqlServer очень часто встречается. Хранимые процедуры необходимы, когда вам нужно сделать сложный запрос. Например, вы хотите собрать некоторые данные о сотруднике по его фамилии. Особенно представьте, что данные в БД выглядят как некое дерево - у вас есть 3 записи об этом сотруднике в таблице A. У вас есть 10 записей в таблице B для каждой записи в таблице A. У вас есть 100 записей в таблице C для каждой записи в Таблица B. И вы хотите получить только 5 специальных записей из таблицы C об этом сотруднике. Без хранимых процедур вы получите много трафика запросов между appServer и sqlServer и много кода в appServer. С помощью хранимой процедуры, которая принимает фамилию сотрудника, получает эти 5 записей и возвращает их в appServer, вы 1) уменьшаете трафик в сотни раз, 2) значительно упрощаете код appServer.

Answer 5

"у этого подхода есть следующие недостатки: ... Бизнес-логика входит в базу данных. "

Поскольку под "бизнес-логикой" вы подразумеваете "применение бизнес-правил", СУБД ИМЕННО именно там, где "бизнес-логика" принадлежит.

Answer 6

Это почти полностью зависит от контекста.

Выполнение работы на сервере, а не на клиентах, как правило, является плохой идеей, поскольку делает ваш сервер менее масштабируемым. Однако вы должны сбалансировать это с ожидаемой рабочей нагрузкой (если вы знаете, что у вас будет только 100 пользователей в закрытой среде, вам может не понадобиться масштабируемый сервер) и затратами на сетевой трафик (если вам нужно прочитать много данных для применения вычислений / процессов, тогда может быть дешевле / быстрее выполнять эти вычисления на сервере и отправлять результаты только по сети).

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

Конечно, использование хранимых процедур вместо выполнения динамически скомпилированных операторов SQL может быть более эффективным (он предварительно скомпилирован, и код не нужно загружать на сервер) и помогает инкапсуляции для повышения целостности / безопасности базы данных. Но, судя по всему, вы говорите о массах бизнес-логики, а не о простых мерах по обеспечению эффективности и безопасности.

Как и в большинстве случаев, необходим разумный компромисс / баланс. Хранимых процедур следует использовать достаточно для повышения эффективности и безопасности, но вы не хотите, чтобы ваш сервер стал масштабируемым.

Answer 7

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

Преимущества, которые я почувствовал, могут быть

• Воспользуйтесь всеми возможностями БД.
• Интенсивная работа с базой данных , например, вставка / обновление может быть лучше выполнено на уровне БД. Вызовите SP и позвольте ему делать всю работу вместо нескольких ударов по БД.
• Новые серверы БД могут выполнять сложные операции, поэтому они больше не воспринимают это как узкое место. О да, мы использовали Oracle.

Глядя на это сейчас, я думаю, что немногие вещи могли бы быть лучше выполнены на уровне приложений и меньше на уровне БД.

Answer 8

Я не думаю, что они есть. Вы совершенно правы, что перемещение BL в базу данных плохо, но не для всего. Попробуйте взглянуть на Domain Driven Design . Это противоядие от огромного количества SPROC. Я думаю, что вы должны использовать свою базу данных как место для хранения своих бизнес-объектов, ничего более.

Тем не менее, SPROC могут быть гораздо более эффективными при выполнении некоторых простых функций. Например, вы можете увеличить зарплату каждому сотруднику вашей базы данных на фиксированный процент. Это быстрее сделать через SPROC, чем вытащить всех сотрудников из БД, обновить их и затем сохранить обратно.

Answer 9

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

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

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