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

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

Я расскажу, почему в промышленном программировании так делать не надо.

Масштабирование производительности. У приложений и базы данных различные возможности масштабирования при росте нагрузки на систему. Обычные приложения на современных фреймворках легко запустить в несколько копий на разных серверах. А вот базу данных «запустить» на нескольких серверах не так просто. Чтобы снизить нагрузку на чтение, применяют репликацию master-slave. Снизить нагрузку на запись сложнее. Но, возможно, к этим методам и не придется прибегать, если просто не создавать лишнюю нагрузку на базу данных и держать бизнес-логику в приложении.

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

Автоматизация разработки. БД как хранилище данных — стандартная практика. Для упрощения разработки в такой парадигме есть развитые инструменты — библиотеки ORM, которые умеют, в частности, автоматически генерировать скрипты миграции структуры БД. Изменение бизнес-логики в коде облегчается средствами среды разработки: автодополнением, автоматическим рефакторингом. Пользовательские функции в БД придется изменять полностью вручную.

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

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

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

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

Радиационное загрязнение больницы в Северодвинске

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

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

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

Я закрываю лицо ладонями. Массирую себе глаза. И задаю немой вопрос: как такое могло произойти? Как? И у меня нет ответа. Где тот человек, который принял это решение?

И еще более невероятным кажется происшедшее, когда все посмотрели и обсудили сериал «Чернобыль».

Сначала врешь об украденных миллиардах. Потом о результатах выборов. И вот уже врешь о радиационном загрязнении: «Они не опасны для вас, работайте».

← сюда туда →