Какую бизнес-логику должна реализовать база данных?

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

Какой из этих подходов в целом лучше?

Плюсы реализации бизнес-логики в БД, о которых я могу думать:

• Централизация бизнес-логики;
• Независимость от типа приложения, языка программирования, ОС и т. Д .;
• Базы данных менее подвержены миграции технологий или большим рефакторингам (AFAIK);
• Никаких переделок по переносу технологий приложений (например: .NET на Java, Perl на Python и т. Д.).

Минусы:

• SQL менее продуктивен и более сложен для программирования бизнес-логики из-за отсутствия библиотек и языковых конструкций, предлагаемых большинством прикладных языков;
• Более сложное (если вообще возможно) повторное использование кода через библиотеки;
• Менее продуктивные IDE.

Примечание: базы данных, о которых я говорю, являются реляционными, популярными базами данных, такими как SQL Server, Oracle, MySql и т. Д.

Спасибо!

Бизнес логика не входит в базу данных

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

Базы данных делают несколько вещей действительно хорошо:

1. Они хранят и получают данные
2. Они устанавливают и обеспечивают связь между различными объектами данных
3. Они предоставляют средства для запроса данных для ответов
4. Они обеспечивают оптимизацию производительности.
5. Они обеспечивают контроль доступа

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

И, конечно, могут быть вещи, которые выполняются в базе данных для производительности и по другим причинам:

1. Закрытие отчетного периода
2. Хруст номера
3. Ночные пакетные процессы
4. Отказоустойчивость

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

Хранимые процедуры везде

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

Но чем вы рискуете?

1. Блокировка поставщика
2. Потребность в разработчиках со специальными наборами навыков
3. Спартанские инструменты программирования, в целом
4. Чрезвычайно жесткая программная связь
5. Нет разделения интересов

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

Итак, что является типичной практикой?

Я бы сказал, что типичным современным подходом является использование Object-Relational Mapper (например, Entity Framework) для создания классов, моделирующих ваши таблицы. Затем вы можете обращаться к своей базе данных через репозиторий, который возвращает коллекции объектов, и эта ситуация хорошо знакома любому компетентному разработчику программного обеспечения. ORM динамически генерирует SQL, соответствующий вашей модели данных и запрашиваемой информации, который затем обрабатывает сервер базы данных для возврата результатов запроса.

Насколько хорошо это работает? Очень хорошо и гораздо быстрее, чем написание хранимых процедур и представлений. Обычно это покрывает около 80% ваших требований к доступу к данным, в основном CRUD. Что покрывает остальные 20%? Вы уже догадались: хранимые процедуры, которые все основные ORM поддерживают напрямую.

Можете ли вы написать генератор кода, который делает то же самое, что и ORM, но с хранимыми процедурами? Что вы можете. Но ORM, как правило, независимы от поставщиков, понятны всем и лучше поддерживаются.

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

Я оспариваю ваши плюсы и минусы.

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

select <whatever>
from group g
where fn_invoker_has_access_to_group(g.group_id)

Проблема этого подхода заключается в том, что обычно (в некоторых случаях это ложно) заставляет базу данных запускать вашу функцию N раз, по одному на строку. Иногда эта функция стоит дорого. Некоторые базы данных поддерживают индексы функций. Но вы не можете индексировать каждую возможную функцию для каждого возможного ввода. Или ты можешь?

Распространенным решением вышеупомянутой проблемы является извлечение логики из функции и объединение ее в запрос. Теперь вы нарушили инкапсуляцию и дублировали логику.

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

declare some_cursor
while some_cursor has rows
    exec some_other_proc
end

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

В целом, я считаю, что базы данных плохи в:

1. вычисление
2. Итерация (они оптимизированы для операций над множествами)
3. Балансировки нагрузки
4. анализ

Базы данных хороши в:

1. Блокировка и разблокировка
2. Ведение данных и их взаимосвязи
3. Обеспечение целостности

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

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

Я предпочитаю, чтобы код базы данных был ориентирован на постоянство. Как вы создаете новый виджет? Вы должны вставить в 3 таблицы, и они должны быть в транзакции. Это принадлежит хранимой процедуре.

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

Я работал в 2 разных компаниях, которые имели разные взгляды на эту тему.

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

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

Поэтому используйте хранимую процедуру с осторожностью, когда это необходимо.

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

Как вы заметили, T-SQL (или его эквивалент в других популярных РСУБД) - не самое лучшее место для кодирования сложной бизнес-логики.

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

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

http://en.wikipedia.org/wiki/Set_operations_(SQL)

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

Хотя это не жесткие и быстрые правила, это хорошая отправная точка.

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

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

Через несколько лет вопрос все еще важен ...

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

Избегайте мусорных БД

Попытки поместить действительно всю бизнес-логику в код приложения, вероятно, приведут к вырождению (реляционной) базы данных в дамп мусора, где реляционный дизайн в основном полностью пропущен, где данные могут иметь любое несовместимое состояние и отсутствует нормализация (часто в основном XML, JSON). , CSV и др. Мусорные колонки).

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

Выражения (на основе набора) вместо процедурного кода

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

Использовать механизмы целостности данных БД

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

Хранимые процедуры?

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

Хотя сторона приложения, включая сгенерированный ORM, SQL больше не находится внутри базы данных, в отличие от хранимых процедур, я все равно считаю это кодом базы данных. Потому что он все еще требует знания SQL и базы данных (кроме самого простого CRUD) и, при правильном применении, работает значительно иначе, чем процедурный код, обычно создаваемый с помощью языков программирования, таких как C # или Java.

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

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

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

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

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

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

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