Хранимые процедуры нарушают трехуровневое разделение?

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

Я думаю, что мир был бы очень мрачным местом без хранимых процедур.

Действительно ли они нарушают трехуровневое разделение?

Ваши коллеги связывают архитектуру с реализацией.

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

Давайте рассмотрим трехуровневое приложение, в котором два уровня реализованы в базе данных:

• Уровень данных: Состоит из таблиц базы данных , доступ с помощью четырех стандартных операций таблицы ( INSERT, UPDATE, DELETEи SELECT).
• Уровень логики: состоит из хранимых процедур, которые реализуют только бизнес-логику и получают доступ к уровню данных, используя только методы, описанные выше.
• Уровень представления. Состоит из веб-сервера, на котором выполняется код, который обращается к логическому уровню, выполняя только вызовы хранимых процедур.

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

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

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

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

Совет Этвуда от 2004 года звучит правдоподобно и сегодня, только теперь у нас есть преимущество ORM.

http://blog.codinghorror.com/who-needs-stored-procedures-anyways/

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

Краткое резюме: Это действительно зависит от вашего использования хранимых процедур и бизнес-требований.

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

Говоря о терминологии, в общих словах эти уровни описываются как:

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

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

Преимущества трехуровневых конструкций:

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

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

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

Слой - это логический механизм структурирования элементов, составляющих ваше программное решение; Уровень - это механизм физического структурирования инфраструктуры системы. ( Ссылка )

На мой взгляд, существуют две основные проблемы построения бизнес-логики в базе данных:

1. Код и библиотеки: вы найдете меньше программистов, способных программировать на SQL, PL / SQL, TSQL и т. Д., Чем на C #, Java и т. Д. Языки программирования также обладают преимуществом отличных IDE, великолепных библиотек и сред.

2. Горизонтальная масштабируемость: единственный способ масштабировать вашу систему - это заменить физический сервер, на котором база данных, более мощным, что довольно дорого (сервер с 64 ГБ ОЗУ); реляционные базы данных масштабируются горизонтально очень плохо, и даже при больших затратах. В то время как с бизнес-логикой в ​​OO-встроенном сервере вы можете довольно хорошо масштабировать по горизонтали, размещая сервер на многих узлах (в Java многие серверы приложений поддерживают это).

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

1. Если вы используете базу данных Oracle, вам следует использовать PL / SQL в максимально возможной степени, потому что наверняка компании, которые инвестируют, будут придерживаться оракула как минимум даже через 10 лет. Если вчера в приложениях вы использовали Oracle Forms, сегодня .net Web формы, затем MVC, то завтра вы будете использовать angularjs и просто нуждаетесь в перезапуске apis. Если ваша максимальная логика в базе данных, вы можете легко перейти на новые технологии переднего плана.
2. Разработка баз данных очень быстрая и очень эффективная с точки зрения производительности. Просто чтобы дать вам перспективу. В нашем проекте было 7 разработчиков приложений и один разработчик базы данных, и 80% логики было в базе данных.
3. Если вы используете oracle, вы можете использовать утилиты для прямого преобразования процедур вашей базы данных в Res full Api.

Самый сильный аргумент, который приводят разработчики приложений, заключается в том, что бизнес-логика должна быть независимой от базы данных, чтобы вы могли легко изменить базу данных. Я думаю, что если компания использует оракула, почему она переключится на другую технологию, то шансы получить устаревшую логику приложения более ожидаемы. Проблема в основном в том, что не хватает нового таланта ресурса базы данных, в основном парни начинают с простых сайтов, где они используют mysql или sqlserver. Эти ребята затем становятся руководителями и имеют эмоциональную привязанность к уровню приложений :), они даже не хотят понимать или спорить.