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

42

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

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

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

Тулаинс Кордова
источник
9
Просто спросите их, не слышали ли они об архитектуре 3 1/2 уровня ...
dreza
7
Помните, что уровни и слои не одно и то же.
NoChance
2
@ emmad-kareem Этот вопрос помог мне ( stackoverflow.com/questions/120438/… ). Проблема в том, что в технической литературе на испанском (мой родной язык) используется одно слово («капа»), тогда как в английском есть два совершенно разных слова.
Тулаинс Кордова
1
@ user1598390, вы правы, может возникнуть путаница, особенно из-за того, что в мире программного обеспечения недостаточно строгости, когда речь идет об определениях на одном языке, не говоря уже о разных языках.
NoChance
1
Трехуровневая архитектура - это логическая концепция, а не физическая концепция. Вы можете реализовать бизнес-правила с помощью хранимых процедур, и пока они физически находятся в базе данных, эти хранимые процедуры все еще являются частью уровня бизнес-логики.
Крейг

Ответы:

33

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

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

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

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

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

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

Blrfl
источник
2
Так я могу им их, что хранимые процедуры являются частью логического уровня, с точки зрения архитектуры, независимо от того, что они хранятся в базе данных?
Тулаинс Кордова
3
@ user1598390: да. Хотя это будет слой, скажем, 3 слоя, а не 3 уровня.
Jmoreno
4
@ user1598390: Вы можете сказать это, пока можете это доказать. В первый раз, когда уровень представления SELECTнепосредственно из таблиц (уровень данных), модель была нарушена.
Blrfl
@blrfl Об этом я позаботился;)
Тулаинс Кордова
2
@ user1598390: это хорошо, просто помните, что целью является логическое разделение проблем, а не размещение вещей на другом оборудовании.
Jmoreno
19

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

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

dasblinkenlight
источник
7
+1 за упоминание о том, что иногда вы хотите, чтобы некоторая логика существовала в базе данных по соображениям производительности, потому что СУБД, как правило, будет устанавливать порядок операций быстрее, чем код вашего приложения. Хотя очевидно, что это только в тех случаях, когда производительность критична и не может быть достигнута в коде приложения, подавляющее большинство современных приложений, поддерживаемых базой данных, являются приложениями CRUD и для таких преимуществ не используются.
Джимми Хоффа
1
аминь. Люди, кажется, думают, что sprocs = бизнес-код. Их следует рассматривать как БД «API», и тогда они имеют больше смысла. Конечно, они также могут исправить крайние случаи, когда вам нужна производительность и из вашей логики!
gbjbaanb
5

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

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

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

Патрик Салапски
источник
В моем 20-летнем опыте работы в большой компании хранимые процедуры не используются для возврата строк (для этого используются представления), а также не используются для каждой простой вставки или обновления (для этого используется встроенный sql). Они используются главным образом для длительных операций, которые не требуют взаимодействия с пользователем, требующих итерации больших наборов данных для суммирования и выполнения вставок или обновлений на основе некоторой бизнес-логики на основе строк, таких как закрытие в конце месяца или ежедневная пакетная обработка транзакций. , Автор статьи, кажется, использует хранимые процедуры для возврата строк, и поэтому он их нагревает.
Тулаинс Кордова
3

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

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

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

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

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

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

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

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

Е.Л. Юсубов
источник
2

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

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

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

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

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

m3th0dman
источник
-1

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

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

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

Фархан Али
источник
«Если вы используете базу данных Oracle, вам следует использовать PL / SQL в максимально возможной степени». Хранимые процедуры увеличивают нагрузку на систему с самой узкой и труднодоступной системой в архитектуре. С ними также трудно справляться с точки зрения контроля версий и модульного тестирования: «Потому что наверняка компании, которые инвестируют, будут придерживаться оракула как минимум даже через 10 лет». Это просто чепуха. Что заставляет вас думать, что? Если вы наполняете свою систему глупым процедурным мусором PL / SQL, вы можете помешать компании перейти к чему-то современному. Это может быть правдой.
JimmyJames