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

45

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

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

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

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

Vetle
источник
13
Мне также было бы интересно, могут ли сторонники размещения логики приложения на уровне базы данных предоставить методы модульного тестирования этой логики приложения.
Крис Бакетт
@ChrisB: для Oracle есть plunit.com/index.htm
Тони Эндрюс
10
Бизнес логика, а не логика приложения - цель должна быть предметной областью, а не выбором технологии!
Фил Лелло
1
@ChrisB: Могу поспорить, что они могут - заполнить таблицы данными (вам нужно создать фиктивные классы на уровне приложения), а затем автоматически вызвать SP с помощью скрипта. Все это можно записать в виде сценария операторов SQL, очистки и настройки по мере необходимости. Вот ссылка на инструменты для 3-модульного тестирования SQL: toadworld.com/BLOGS/tabid/67/EntryId/67/…
gbjbaanb
Я недавно
высказал

Ответы:

38

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

  1. Тестируемость . На самом деле это должно быть достаточно веской причиной.
  2. Лучшая структура кода . Соблюдать правильную ОО-архитектуру с помощью SQL очень сложно. Обычно это также облегчает поддержку кода.
  3. Проще кодировать . Из-за различных языковых возможностей, доступных на любом языке, который вы используете, обычно проще кодировать на прикладном уровне.
  4. Повторное использование кода . Гораздо проще делиться кодом с библиотеками, чем делиться кодом в базе данных.
Яко Преториус
источник
5
Можем ли мы также добавить возможность управления исходным кодом объектов по мере их изменения? Может быть, это просто моя личная хватка ... (да, я явно опускаю способы, которыми это можно сделать ...)
jcolebrand
6
Re: 4. Отлично! Давайте использовать эту VB-логику в моем приложении Solaris Java ... о, подождите ...
Фил Лелло,
11
Фил, отлично! Давайте использовать вашу логику Oracle в моем приложении SQL Server ... о, подождите ...
Крейг,
9
@Craig Реальность такова, что организации меняют поставщиков баз данных гораздо реже, чем они переключают приложения или языки. Тем не менее, моя точка зрения заключалась в том, что это не преимущество app перед db, а не то, что db здесь лучше; есть плюсы и минусы любого подхода
Фил Лелло,
1
@jcolebrand - Ну, если вы занимаетесь разработкой баз данных , тогда VS 2010 - это бомба. Я перевожу нашу группу из SSMS в VS для разработки и смотрю, как внедрить этот TDD, который в моде у разработчиков. Это выгодное вложение времени для любого магазина, занимающегося значительными разработками баз данных (и, конечно, ориентируясь на SQL Server).
Ник Чаммас
11

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

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

ChrisF
источник
4
«не так просто, как с кодом приложения», почему бы и нет?
НимЧимпский
@Nim - если я не делаю это неправильно, это затрагивает проекты баз данных, а не простое «отредактируйте его, и оно проверено», которое вы получаете, когда контроль исходных кодов интегрирован в вашу IDE.
ChrisF
1
Я полагаю, потому что вы можете вносить изменения в свою базу данных без привязки к управлению версиями, но вы не можете сделать то же самое с кодом ...
Jaco Pretorius
5
@Jaco Нет, но вы можете запускать / выпускать код, не помещая его в SCM. Небрежное управление релизами - это небрежное управление релизами независимо от используемой вами технологии.
Фил Лелло
3
Если вы вносите все изменения в сценарии, то просто сохраняете их в каталоге управления исходными кодами и регистрируете, как и любой другой код, нет никаких сомнений в том, почему трудно работать с базой данных управления исходным кодом.
HLGEM
8

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

Вальтер
источник
Расширить размер команды достаточно сложно, не включая кого-то, кто не будет сотрудничать (не уверен, почему ответственное лицо допускает этот выбор) или требует своего собственного «занятия с репетитором», чтобы ускорить выполнение требований.
Джеффо
1
Я думаю, это потому, что они большую часть времени сидят без дела, поэтому, когда вы наконец даете им что-то для обзора, они действительно хотят привлечь внимание. Может быть, это только я ...
Жак Преториус
5
@Jeff O Почему администратор не участвовал в разработке? Администраторы баз данных, как правило, знают гораздо больше об оптимизации баз данных, чем другие разработчики, и должны рассматриваться как часть команды.
Фил Лелло
8
@Phil Lello: Потому что большинство разработчиков программного обеспечения - высокомерные люди, которые думают, что могут научиться всему этому сами. Вот почему так много баз данных являются такими кучами мусора.
ПРОСТО МОЕ правильное мнение
2
Похоже, ваш дба построил забор вокруг минного поля, чтобы вы были в безопасности. Будьте благодарны!
Джеймс Андерсон
7

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


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

BCS
источник
Этот. Вы хотите, чтобы ваша база данных была устойчивой. Поэтому логика, связанная с вашими данными, должна находиться там.
Арх
6

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

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

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

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

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

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

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 должен управлять потоком данных туда и обратно. Если вы не можете разрешить приложениям подключаться напрямую к таблицам, по крайней мере, вы можете настроить механизм доступа на современные языки.

Кристофер Махан
источник
5
Я действительно не следую за точкой деградации базы данных; Поместив логику в базу данных, вам нужно всего лишь изменить правила в одном месте (базе данных), а не много приложений, написанных на многих языках. Однако +1 за хорошо продуманный ответ.
Фил Лелло
3
Я должен отметить, что многие разработчики, которые считают, что все логическое должно идти в приложении, включают в себя целостность данных. Это одна из причин, почему так много баз данных имеют плохую целостность данных. И производительность является одним из трех наиболее важных факторов для базы данных (наряду с целостностью данных и безопасностью), поэтому, конечно, мы обеспокоены этим!
HLGEM
1
Данные так же хороши, как и приложение. Мусор в мусор, и все такое. Если у вас есть, к сожалению, не совсем точные люди, пишущие приложения, вы очень мало можете сделать как администратор базы данных, чтобы исправить мусор.
Кристофер Махан
1
@ChristopherMahan, вы можете многое сделать в дизайне базы данных, чтобы предотвратить неверные данные.
HLGEM
4

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

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

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

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

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

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

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

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

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

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

М. Смит
источник
Хорошо сказано. Моя большая ошибка с хранимыми процедурами, ссылочной целостностью и т. Д. - обработка ошибок. Все часто конечному пользователю предоставляется «процедура ошибки мульчирования YYYY, процедура XXXXXX - sqlcode -666», что приводит к потере времени на вызовы в службу поддержки. Когда простой «у клиента нет налогового идентификатора», пользователь может решить проблему и продолжить работу.
Джеймс Андерсон
3

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

Maniero
источник
3
Очень сложно построить хранилища данных, не зависящие от приложений, с помощью логики на основе приложений
Фил Лелло,
3

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

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

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

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

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

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

Николя де Фонтене
источник
2

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

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

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

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

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

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

JeffO
источник