Бизнес-логика: база данных или прикладной уровень

Question

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

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

Answer 1

Поддержка вашего кода всегда является большой проблемой при определении того, куда должна идти бизнес-логика.

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

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

Answer 2

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

Но не бойтесь дублировать часть этой логики на другом уровне, чтобы улучшить взаимодействие с пользователем.

Answer 3

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

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

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

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

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

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

Answer 4

Это действительно зависит от вас, , если вы последовательны .

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

Одна веская причина поместить его на уровень приложения: если вы нацеливаете несколько технологий персистентности на свое приложение.

Вы также должны принять во внимание основные компетенции. Ваши разработчики в основном разработчики прикладного уровня или они в основном DBA-типы?

Answer 5

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

Некоторые системы, которые я поддерживаю, проходили через следующие пользовательские интерфейсы за последние 10-15 лет: Oracle Forms / Visual Basic / Perl CGI / ASP / Java Servlet. Единственное, что не изменилось - реляционная база данных и хранимые процедуры.

Answer 6

Хотя нет единственного правильного ответа - это зависит от рассматриваемого проекта, я бы рекомендовал подход, предложенный Эриком Эвансом в " Domain Driven Desig n" Эрика Эванса. При таком подходе бизнес-логика изолируется на своем собственном уровне - уровне домена - который расположен поверх уровня (ов) инфраструктуры - который может включать код вашей базы данных, и ниже уровня приложения, который отправляет запросы на уровень домена для выполнения и слушает для подтверждения их завершения, эффективно управляя заявкой.

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

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

Answer 7

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

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

Answer 8

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

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

Возможность использования SP также сильно зависит от базы данных, которую вы собираетесь использовать. Если вы не учитываете независимость от базы данных, у вас будет совершенно другой опыт использования T-SQL или PL / SQL.

Если вы используете Oracle для разработки приложения, то PL / SQL является очевидным выбором в качестве языка. Он очень тесно связан с данными, постоянно совершенствуется в каждом случае, и любой достойный инструмент разработки собирается интегрировать разработку PL / SQL с CVS или Subversion или чем-то подобным.

Веб-среда Oracle для разработки приложений Express даже на 100% построена на PL / SQL.

Answer 9

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

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

Конечно, есть большая разница между способностью объединять оператор SQL и "сильными навыками работы с базами данных" - если ваша команда ближе к первому, чем ко второму, тогда поместите логику в приложение, используя один из спящих этого мира (или измени свою команду!).

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

Надеюсь, это поможет.

Answer 10

В настоящее время возможно представить в subversion ваш сохраненный код proc и отладить этот код с хорошей поддержкой инструментов.

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

Как только мы начали сборку в C #, мы приняли решение не использовать хранимые процессы, но теперь мы перемещаем все больше и больше кода в хранимые процедуры. Особенно пакетная обработка.

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