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

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

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

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

Редактировать Этот вопрос также рассматривается на dba.se , с точки зрения администраторов баз данных. Поскольку programmers.se & dba.se имеют разную аудиторию и пристрастия, будущие читатели могут захотеть просмотреть оба набора ответов, прежде чем решить, что для них лучше.

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

1. Тестируемость . На самом деле это должно быть достаточно веской причиной.
2. Лучшая структура кода . Соблюдать правильную ОО-архитектуру с помощью SQL очень сложно. Обычно это также облегчает поддержку кода.
3. Проще кодировать . Из-за различных языковых возможностей, доступных на любом языке, который вы используете, обычно проще кодировать на прикладном уровне.
4. Повторное использование кода . Гораздо проще делиться кодом с библиотеками, чем делиться кодом в базе данных.

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

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

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

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

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

Прочитав оба вопроса, я думаю, мы все пропустили один критический момент. Правильный ответ может зависеть от типа программного обеспечения, которое вы разрабатываете. Группа DBA в основном работает над критически важными для бизнеса программными системами Enterprise, и их ответы отражают то, что необходимо в этом мире. Существует огромная разница в том, что необходимо для этих типов приложений, чем в следующем приложении «Facebook». Ничего страшного, если вы потеряете пару сообщений на стене, это если вы потеряете пару заказов или другие финансовые транзакции.

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

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

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

Длинноватые. см. Резюме внизу.

RDBMS

СУРБД означает систему управления реляционными базами данных. Это система управления реляционной базой данных. Данные хранятся там. Данные. Это не говорит о бизнес-логике.

Бизнес-процесс

Что на самом деле означает бизнес-логика? Для меня это описание бизнес-процессов в логических терминах.

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

Позвольте мне надеть мою деловую шапку и объяснить, что здесь означает бизнес. Для некоторых это может стать неожиданностью.

Бизнес

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

Быстрый обход: вам понадобится 40 миллионов заклепок за 2 дня, вы не собираетесь заказывать у какого-нибудь парня в Интернете со счетом PayPal, независимо от того, насколько дешевле его цена, чем у вашего обычного продавца.

Знание процесса

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

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

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

Логика приложения

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

Данные

Я также говорю, что данные переживают приложение, поэтому усилия по нормализации данных не должны быть конкретными для приложения и даже не специфичными для бизнеса, а скорее должны быть общими для бизнеса. Вы храните коды штатов? Вы должны использовать INCITS 38: 2009 (http://www.census.gov/geo/www/ansi/statetables.html), потому что это переносимо для предприятий. Это также позволяет нескольким приложениям манипулировать данными.

NoSQL?

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

Актуальный код

Нет, вам нужно рассматривать базу данных как общий репозиторий данных для нескольких приложений, как текущих, так и будущих. Теперь мы подошли к сути моего аргумента. Бизнес-процессы меняются вместе с капризами рынка, политики и моды. Очень часто они меняются быстрее, чем то, с чем могут справиться программисты на языках компьютерного уровня (Java, C #, C ++ и т. Д.), И в конечном итоге пишутся на VBA в электронных таблицах Excel в отделе бухгалтерского учета или маркетинга. (И только если это не может быть выражено в причудливых взглядах ...)

Ухудшение базы данных

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

Резюме

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

Предостережение

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

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

Позже, подумав об этом

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

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

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

Один пользователь на обмене стека DBA заявил это ...

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

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

... Вслед за его убеждением, что это свидетельствует о нарушении принципа СУХОЙ.

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

Их база данных OLTB на протяжении десятилетий надежно и эффективно предоставляет данные для 25+ приложений! Это восхитительно! (Путь!)

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

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

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

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

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

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

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

Это вопрос общения между командами и признания плюсов и минусов каждой возможности.

Мое мнение таково: не делайте логику приложения слишком глубоко в БД.

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

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

• Как бы вы сделали контроль версий?
  • Что такое история кода? Какие были изменения? Кем?
  • Как вы обрабатываете изменения на тех же фрагментах кода?
• Как бы вы определили и гарантировали согласованное состояние кода?

Вы могли бы отследить это в дополнительной файловой VCS, но какова польза от базы данных?

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