Плюсы и минусы проведения всей бизнес-логики в хранимых процедурах в веб-приложении [дубликат]

    

У этого вопроса уже есть ответ:

    

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

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

31 голос | спросил droidsites 28 J000000Saturday12 2012, 03:33:45

6 ответов


46

В теории плюсы и минусы таковы:

Плюсы:

  1. Одно место для размещения всей бизнес-логики
  2. Возможно, более быстрые приложения, поскольку несколько запросов SQL и т. д. могут выполняться в одном «обратном путешествии» в базу данных
  3. Тривиально использовать хранимые процедуры из нескольких приложений

Минусы:

  1. Для настройки производительности потребуется DBA.
  2. Все разработчики должны быть очень хорошо разбираться в вашем конкретном диалекте SQL (T-SQL, Pl /SQL и т. д.).
  3. SQL-код не так выразителен и, следовательно, сложнее писать при освещении концепций более высокого уровня, которые не связаны с данными
  4. Намного больше ненужной нагрузки на базу данных

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

  1. Очень немногие разработчики смогут создать согласованный интерфейс хранимых процедур, который легко работает в приложениях. Обычно это происходит из-за того, что сделаны определенные предположения о вызывающем приложении
  2. То же самое относится к документированию всех этих хранимых процедур.
  3. Серверы баз данных, как правило, достаточно узки, как есть. Наложение ненужной нагрузки на них просто сужает это узкое место. Сложная балансировка нагрузки и многообещающее оборудование потребуются для чего-либо с приличным количеством трафика.
  4. SQL - это всего лишь язык программирования. Я когда-то имел удовольствие поддерживать скриптовый движок, написанный как хранимая процедура T-SQL. Это было медленно, почти невозможно понять, и потребовалось несколько дней, чтобы реализовать то, что было бы тривиальным расширением в большинстве языков.
  5. Что происходит, когда у вас есть клиент, которому нужна их база данных для запуска другого SQL-сервера? Вы в основном должны начать с нуля - вы очень привязаны к своей базе данных. То же самое происходит, когда Microsoft решает отказаться от нескольких функций, которые вы используете несколько сотен раз по своим хранимым процедурам.
  6. Управление источниками чрезвычайно сложно сделать правильно с хранимыми процедурами, более того, когда у вас их много.
  7. Базы данных трудно синхронизировать. Как насчет того, когда у вас есть конфликт между двумя разработчиками, которые работают в базе данных одновременно? Они будут переписывать код друг друга, который не знает об этом, в зависимости от настройки «базы данных разработки».
  8. Инструменты, безусловно, менее просты в работе, независимо от того, какой механизм базы данных вы используете.

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

ответил Earlz 28 J000000Saturday12 2012, 12:23:43
15

Минусы:

  • База данных - это наименьшая масштабируемая часть вашей архитектуры,
  • Особенно в эпоху веб-сервисов и сторонних веб-приложений REST-ful вы не сможете содержать всю свою бизнес-логику в хранимых процедурах.
  • Реализации SQL различаются, некоторые из них могут быть сложными, и ни один из них не читается столь же плавно, как первоклассный язык программирования прикладного уровня.
    • Помните, что код read гораздо чаще, чем .
ответил Jim G. 28 J000000Saturday12 2012, 20:42:37
9

Плюсы использования всей бизнес-логики для хранимых процедур в веб-приложении для:

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

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

  • Хорошие знания SQL могут быть трудно найти во многих местах.
  • Хорошие SQL-кодеры могут быть дорогими.
  • Все разработчики приложений должны иметь возможность либо изменить его, либо запросить быстрое изменение.
  • Некоторые данные, которые менее подходят для базы данных SQL, например. данные изображения или данные документа могут быть недоступны в базе данных, и может быть трудно интегрировать их с хранимыми процедурами.
ответил Michael Durrant 28 J000000Saturday12 2012, 05:04:00
6

Есть два больших минуса, с которыми я обычно сталкиваюсь:

  1. Невозможность модульного тестирования ваших хранимых процедур. Конечно, есть некоторые модульные тестовые среды, но вы обычно сталкиваетесь с проблемами запуска более одного набора тестов сразу (параллелизм и проблемы с транзакциями).
  2. Большинство компаний захотят поместить много логинов в хранимые procs, но затем нанять еще 5 программных программистов (будь то C #, Ruby, Java, что угодно), чем программисты баз данных или администраторы баз данных, и по некоторым причинам ожидают, что все их приложения должны полностью понимать и иметь возможность писать исполняемые, масштабируемые процедуры базы данных (в PL /SQL, T-SQL или что-то еще). Менеджмент обычно не понимает, что это очень похоже на наем специалиста C #, чтобы написать вам код Python и интересно, почему они не пишут потрясающие приложения.
ответил rally25rs 28 J000000Saturday12 2012, 05:46:39
6

Это зависит от

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

Это НЕ имеет значения

Пока бизнес-логика:

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

Я думаю, что business logic in programming space makes more sense, когда Power of Expression важно в вашей команде /проекте.

Я считаю, что пространство SQL не так выразительно, но it can do the job. Используйте лучшие инструменты , которые у вас есть под рукой для наиболее подходящих задач. Взаимодействие с логикой и концепциями более высокого порядка лучше всего делать на highest level. Следовательно, манипуляции с памятью и массовыми данными лучше всего делать на сервере уровне , вероятно, в хранимых процедурах.

ответил EL Yusubov 28 J000000Saturday12 2012, 04:30:52
1

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

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

CON-х Это не код linq. Будущее TSQL скомпилировано linq, мое тоже начнет его изучать.

Скомпилированный код более стабилен и удобен в работе. Если я отлаживаю что-то, доступно столько информации, если я использовал C # или Java.

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

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

Если вам нравится Microsoft Asp.Net MVC в сочетании с Entity Framework Code First, вы сможете быстро создавать любое приложение, и вам не понадобятся какие-либо хранимые процедуры.

ответил Honorable Chow 28 J000000Saturday12 2012, 18:01:25

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132