Каковы аргументы против или для размещения логики приложения на уровне базы данных?

П р и м е ч а н и е - Аудитория programmers.se и dba.se различна и будет иметь разные точки зрения, поэтому в этом случае я думаю, что допустимо дублировать. Каковы аргументы против или для размещения логики приложения на уровне базы данных? на programmers.se.

Я не смог найти обсуждения по dba по этому вопросу, и в оригинальном сообщении все сказано, поэтому:

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

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

Что вы думаете об этом, и что должно или не должно быть хорошо для реализации на уровне базы данных?

NB. Я не являюсь ОП по этому вопросу, но оставил оригинальную формулировку без изменений.

Разные мысли ...

Код вашей базы данных переживет технологию вашего клиентского приложения. Подумайте о ADO.NET -> Linq -> EF, а также о различных ORM. Принимая во внимание, что вы все еще можете запускать код SQL Server 2000 с прошлого тысячелетия против всех вышеупомянутых клиентских технологий.

У вас также есть проблема с несколькими клиентами: у меня есть .net, java и Excel. Это 3 набора логики приложения.

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

Логика приложения не масштабируется для больших объемов данных. У нас есть 50 тыс. Строк в секунду с использованием сохраненных процедур. Сестринская команда, использующая Hibernate, не может получить одну в секунду

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

В последнем Fortune 500, над которым я работал, приложения, написанные как минимум на 25 языках, попали в базу данных OLTP. Некоторые из этих программ были запущены в производство в 1970-х годах.

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

Каковы шансы?

Разве это не самое большое « не повторяйся » на планете?

Я перемещаю свой старый ответ через неотредактированный файл programmers.se, поскольку ответы кажутся довольно поляризованными между сайтами.

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

• Вы можете разрешить бизнес-пользователям прямой доступ к базе данных и не беспокоиться о том, что они облажаются (или беспокоиться меньше, чем с логикой на основе приложений)
• Опытный пользователь может создавать новые отчеты, не дожидаясь новой версии программного обеспечения.
• Вы можете протестировать код SP / TRIGGER в копии базы данных так же, как вы тестируете логику на основе приложений.
• Вы можете сохранить SQL для создания sp и триггеров в текстовых файлах (вы должны делать это в любом случае для кода таблицы / представления)
• Вы можете смешивать и сочетать языки без портирования бизнес-логики
• Вы можете вносить изменения в бизнес-логику, не обновляя каждый бит программного обеспечения
• Вы проверяете структуру изменений так же, как вы проверяете активность базы данных - через ведение журнала
• Значительно улучшенная безопасность и точное управление доступом (большинство реализаций логики на основе приложений используют свою собственную модель безопасности, поэтому данные гораздо легче компрометировать. Обратимое шифрование пароля не редкость)
• Безопасность пользователя на стороне базы данных значительно уменьшает ущерб, который может нанести мошенник SQL

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

Ни один из них не должен иметь значения для опытного разработчика.

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

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

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

…
3. Добавить ограничения целостности / проверки в основную базу данных,с более сложным кодом, реализованным на языке хранимых процедур базы данных. Исходя из этого, мы получаем одно центральное место для обслуживания и получаем абсолютное соблюдение правил даже для приложений, о которых мы не знаем! У нас есть один язык для выражения бизнес-правил на протяжении всего портфеля приложений и жизненного цикла, поскольку язык du jour меняется гораздо чаще, чем база данных. И он работает в системе, которая уже столь же важна, как и самые важные приложения. Ошибки обрабатываются существующим кодом, который обрабатывает ошибки базы данных в этих приложениях. Конечно, существует риск того, что приложение может сломаться, но из трех сценариев это наименьшее, и только сломанное приложение нуждается в модификации. не все из них (и большинство механизмов SP / базы данных позволяют сделать исключение для одного приложения, если это действительно необходимо). Думаете, это не имеет значения на вашем сайте или в маленькой компании? Хорошо, если ваш бизнес преуспеет, через 30 лет вы пожалеете, что обратили внимание на мою мудрость!

… Некоторые [возражения] я часто слышу:

• Трудно контролировать версию SP-кода, развернутого в БД. Я не думаю, что это более правдиво, чем говорить, что трудно контролировать версии Java-кода, развернутого на сервере приложений, то есть это совсем не сложно, это обычное дело. А в Ruby-land написаны целые книги, рассказывающие о том, как получить свой код из среды разработки в производство, с чем, похоже, не сталкивается ни одно другое языковое сообщество. Однако управление версиями хранимой процедуры, по-видимому, слишком сложно.
• Хранимые процедуры сложно проверить. Это странно. Для начала, SP строго типизированы; компилятор скажет вам, есть ли путь к входу или выходу кода, который не имеет смысла, и, по крайней мере, в Oracle, рассчитает все зависимости для вас. Так что это один набор типовых юнит-тестов, которые вам могут понадобиться в Ruby. Для тестирования ОО-кода требуется насмешка для приведения объекта во внутреннее состояние, необходимое для представления сценария тестирования. Чем отличается настройка данных тестирования? Кроме того, есть производитель TAP для PL / SQL и других инструментов. Есть отладчики и профилировщики тоже.
• Язык хранимых процедур не является полнофункциональным языком. Ну, мы не пытаемся написать целое приложение только в хранимых процедурах! Большинство выделенных языков SP имеют все современные конструкции, которые вы ожидаете, и, по крайней мере, в Oracle вы можете использовать хранимые процедуры Java со всеми языковыми функциями, с которыми знакомы разработчики ОО, или внешние процедуры на любом языке. Важно то, где реализована логика - в одном месте, рядом с данными - реальный язык - это просто деталь. PL / SQL компилируется в нативный код и работает внутри базы данных; нет более высокопроизводительной архитектуры, чем эта.
• Я не хочу изучать другой язык. Не обращая внимания на секунду, это огромный красный флаг у любого разработчика (особенно тот, который предлагает модифицировать производственные приложения, которые могут быть на других языках в любом случае!), Есть много, чтобы научиться работать в любой современной среде: типичный магазин Java может иметь Eclipse , WebLogic, Maven, Hudson, Anthill, Subversion и множество других, которые вам необходимо изучить, прежде чем писать одну строчку кода приложения. Рабочие знания языка SP очень высокого уровня просты в сравнении, и, скорее всего, будет специалист или администратор базы данных, который также поможет вам. Не говоря уже о том, что любимый разработчиком Hibernate поставляется с собственным языком запросов…

...

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

Кроме того, как указывало GBN выше, код SQL почти повсеместно переживет код приложения.

Хотя верно то, что EF, NHibernate, LinqToSql или что-то еще позволит вам генерировать код быстрее, каждый программист, достойный своей производительности, знает, что только оптимизация SQL оптимизирует поиск данных. СУБД понимает только SQL, поэтому вам нужно все преобразовать в SQL, прежде чем все будет сказано и сделано. (при условии, что мы можем согласиться с тем, что TSQL и PLSQL по-прежнему являются SQL)

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

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

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

Для некоторых продуктов СУБД существуют превосходные библиотеки / инструменты / API для бизнес-логики и объектной инфраструктуры, которые можно быстро освоить и использовать в их приложениях. Для других СУБД нет библиотек / инструментов / API.

В прошлом приложения клиент-сервер делали мост в BL с помощью хранимых процедур (SP). Для таких продуктов, как Oracle и SQL Server, это было сделано рано. С появлением баз данных с открытым исходным кодом, таких как PostgreSQL и MySQL, те, кто их использует, рискуют выйти на новый уровень с помощью хранимых процедур в BL. PostgreSQL очень быстро стал зрелым, так как были реализованы не только хранимые процедуры, но и возможность создавать языки клиентов. MySQL в основном прекратил развиваться в мире хранимых процедур и появился в урезанной форме языка со многими ограничениями. Таким образом, когда дело доходит до BL, вы полностью зависите от MySQL и его языка хранимых процедур.

На самом деле остается только один вопрос: независимо от СУБД, BL должен полностью или частично находиться в базе данных?

Подумайте о разработчике. Когда в приложении что-то идет не так, процесс отладки будет заставлять разработчика входить и выходить из базы данных, чтобы следовать изменениям данных, которые могут быть или не быть правильными с перерывами. Это похоже на кодирование приложения C ++ и вызов кода ассемблера в середине. Вы должны переключиться с исходного кода, классов и структур на прерывания, регистры и смещения И НАЗАД !!! Это выводит отладку на тот же уровень.

Разработчики могут создать высокоскоростной метод выполнения BL в сочетании с языковыми конфигурациями (флаги компилятора для C ++, различные настройки для PHP / Python и т. Д.) С помощью бизнес-объектов, находящихся в памяти, а не в базе данных. Некоторые пытались объединить эту идеологию для более быстрого выполнения кода в базе данных, написав библиотеки, в которых отладка хранимых процедур и триггеров хорошо интегрирована в базу данных и кажется бесполезной для использования.

Таким образом, перед разработчиком стоит задача разработать, отладить и поддерживать исходный код и BL в двух языках.

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

Теперь для встречи умов !!!

Разработчик кодирует SP и использует итеративные методы. DBA смотрит на SP. DBA определяет, что один оператор SQL может заменить итеративные методы, написанные разработчиком. Разработчик видит, что оператор SQL, предложенный администратором базы данных, требует вызова другого кода, связанного с BL, или SQL, который не соответствует обычным планам выполнения оператора SQL.

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

ЗАКЛЮЧЕНИЕ

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

Это хороший вопрос, чтобы задать на веб-сайте, полном DBA. Надеемся, что большинство ответов будет "за" в отношении поддержания базы данных в состоянии ACID и, следовательно, сохранения бизнес-логики в базе данных. :-)

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

Как сказал выше Адам Муш, здесь есть еще что посмотреть на производительность. Использование процессора. Использование памяти.

Блокировать явно неправильные вещи от попадания в базу данных.

• Отсеять адреса электронной почты, которые не соответствуют каким-либо основным принципам.
• Проверьте длину

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

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

Используйте сильные стороны каждого конца в свою пользу.