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

Question

Я не хочу снова задавать классический вопрос «бизнес-логика в базе данных против кода», но мне нужны некоторые конкретные причины, чтобы убедить старшую команду разработчиков, что бизнес-логика в коде лучше, потому что она более удобна в обслуживании, прежде всего,Раньше у меня было много бизнес-логики в БД, потому что я верил, что это единственная точка доступа.Техническое обслуживание легко, если бы я был единственным, кто менял его.По моему опыту, проблемы возникли, когда проекты стали больше и сложнее.Управление исходным кодом для хранимых в БД Procs не так продвинуто, как для более новых IDE, как и редакторов.Бизнес-логика в коде может масштабироваться намного лучше, чем в БД, это то, что я обнаружил в своем недавнем опыте.

Итак, просто просматривая stackoverflow, я обнаружил совершенно противоположную философию от его уважаемых членов:

https://stackoverflow.com/search?q=business+logic+in+database

Я знаю, что нет абсолюта для любой ситуации, нодля данного решения asp.net, в котором будет использоваться сервер sql или oracle, для сайта с не очень высоким трафиком, зачем мне помещать логику в БД?

Answer 1

Зависит от того, что вы называете бизнесом.

База данных должна делать то, что ожидается.

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

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

Мне кажется, что с точки зрения систем и компонентов база данных похожа на любой другой сервис или класс / объект. Он должен защищать свой периметр, скрывать детали своей реализации и предоставлять гарантии целостности, от целостности низкого уровня до определенного уровня, который можно считать «деловым».

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

Answer 2

База данных работает с данными, зачем взвешивать что-то, что уже достаточно сильно ударило, чтобы дать вам данные. Это вопрос производительности и кода. Гораздо проще поддерживать код бизнес-логики, чем хранить все это в базе данных. Sprocs, Views и Functions могут зайти так далеко, пока у вас не появятся представления Views of Views с sprocs для заполнения этого беспорядка. С помощью бизнес-логики вы разделяете свои заботы. Если у вас есть ошибка, из-за которой что-то вычисляется неправильно, проще проверить код бизнес-логики, чем зайти в БД и посмотреть, не испортил ли кто-то что-то в хранимой процедуре. Это очень самоуверенно, и в некоторых случаях это нормально, чтобы поместить некоторую логику в базу данных, но я думаю, что это база данных, а не логическая база, поместите вещи туда, где они принадлежат.

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

РЕДАКТИРОВАТЬ: То, что Кейд упомянул, что я забыл. Относительная целостность. Во что бы то ни стало, пожалуйста, сохраняйте правильную целостность данных в вашей БД, никаких осиротевших записей НА УДАЛЕННЫХ КАСКАДАХ, чеках и еще много чего.

Answer 3

Я столкнулся с логикой базы данных на одном из огромных проектов.Это было вызвано решением главного менеджера, который был специалистом DBA.Он сказал, что приложение должно быть легковесным, оно не должно ничего знать о схеме базы данных, объединенных таблицах и т. Д., И в любом случае хранимые Procs выполняются намного быстрее, чем области транзакций и запросы от клиента.С другой стороны, у нас было слишком много ошибок с отображениями объектов базы данных (сохраненный продукт или представление, основанное на представлении, основанном на другом представлении и т. Д.).Было невозможно понять, что происходит с нашими данными, потому что каждое нажатие кнопки вызывало огромный хранимый процесс с параметрами 70-90-120 и обновлял несколько (10-15) таблиц.У нас не было возможности запросить простой запрос на выборку, поэтому нам пришлось скомпилировать представление или сохраненный Proc и класс в коде для этого только для одного простого объединения :-( конечно, когда изменяется определение таблицы или представления, вам следует перекомпилировать все другие объекты на основе дБ.на редактируемом объекте в другом месте вы получите исключение времени выполнения. Поэтому я думаю, что логика в базе данных - ужасный способ. Конечно, вы можете хранить некоторые куски кода в хранимых процессах, если это необходимо из-за проблем с производительностью или безопасностью, но вы не должны разрабатывать все вБаза данных) логика должна быть гибкой, тестируемой и обслуживаемой, и вы не можете достичь этой точки, используя базу данных для хранения логики)