Использование StoredProcs в приложении

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

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

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

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

оцените вашу помощь.

ТНХ -ksm

ОТВЕТЫ

Ответ 1

Здесь открыта причина в пользу хранимых процедур: Зачем использовать хранимые процедуры?

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

Говоря это, я сейчас буду склонен:

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

Нет ответа "да" или "нет"

Ответ 2

Мое мнение о том, что ВСЕ запросы выполняются с помощью хранимых процедур

Точка 1:

Это было ДЕЙСТВИТЕЛЬНО полезно в те дни, когда уровень DAL был не очень распространенным, потому что выполнение этого через SP обеспечивало такую ​​же уверенность, что ваши изменения в БД никогда не повлияют на лежащие слои, отличные от 1.

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

Точка 2:

Кроме того, в более старых базах данных (по крайней мере, SQL Server 7 и, возможно, даже 2000) было преимущество в производительности из-за кэширования планов выполнения SP, поскольку из-за этого выполнение медленного SQL будет медленнее.

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

Точка 3:

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

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

Резюме: Я лично считаю, что форсирование SP для каждого запроса старомодно. нет вреда для этого. Но мне очень сложно думать о какой-либо реальной выгоде для этого, если у вас есть уровень DAL/Business и механизм DB, достаточный для кэширования ваших планов запросов для ваших запросов.

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

Предполагается, что ваша хранимая процедура запрашивает данные и не изменяет данные.

Как только вы начнете использовать хранимые процедуры и получите удобство с ними, вы скажете себе: "Вау, мне жаль, что я давно их не использовал".

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