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

Question

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

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

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

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

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

ТНХ -ksm

Answer 1

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

Точка 1:

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

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

Точка 2:

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

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

Точка 3:

Кроме того, в старых системах в базу данных встраивалось много бизнес-логики. Внедрение бизнес-логики в базу данных означало написание ДЛИТЕЛЬНЫХ и сложных процедур. Таким образом, поскольку процедуры в любом случае присутствовали, стало полезно сделать их согласованными, сказав «давайте сделаем все процедурой»

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

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

Answer 2

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

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

Сказав это, я бы склонялся в настоящее время:

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

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

Answer 3

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

Answer 4

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

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

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

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

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

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

Answer 5

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