Каковы плюсы и минусы сохранения SQL в сохраненных процедурах по сравнению с кодом [закрыто]
https://stackoverflow.com/questions/15142
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Каковы преимущества / недостатки сохранения SQL в вашем исходном коде C # или в сохраненных процедурах?Я обсуждал это с другом в проекте с открытым исходным кодом, над которым мы работаем (C # ASP.NET Форум).На данный момент большая часть доступа к базе данных осуществляется путем создания встроенного SQL на C # и вызова базы данных SQL Server.Поэтому я пытаюсь определить, что для данного конкретного проекта было бы лучше.
До сих пор у меня есть:
Преимущества для встроенного кода:
- Проще в обслуживании - не нужно запускать SQL-скрипт для обновления запросов.
- Проще перенести в другую базу данных - нет процедур для переноса
Преимущества для хранимых процессов:
- Производительность
- Безопасность
Решение
Я не поклонник хранимых процедур
Хранимые процедуры БОЛЕЕ удобны в обслуживании, потому что:* Вам не нужно перекомпилировать ваше приложение на C # всякий раз, когда вы хотите изменить какой-либо SQL
В конечном итоге вам все равно придется перекомпилировать его, когда изменятся типы данных, или вы захотите вернуть дополнительный столбец, или что-то еще.Количество раз, когда вы можете "прозрачно" изменять SQL из-под вашего приложения, в целом довольно мало
- В конечном итоге вы повторно используете SQL-код.
В языках программирования, включая C #, есть такая удивительная вещь, которая называется функцией.Это означает, что вы можете вызвать один и тот же блок кода из нескольких мест!Потрясающе!Затем вы можете поместить повторно используемый SQL-код внутрь одного из них, или, если вы хотите получить действительно высокие технологии, вы можете использовать библиотеку, которая сделает это за вас.Я полагаю, они называются объектно-реляционными картографами и довольно распространены в наши дни.
Повторение кода - это худшее, что вы можете сделать, когда пытаетесь создать поддерживаемое приложение!
Согласен, именно поэтому storedprocs - это плохо.Гораздо проще реорганизовать и разложить (разбить на более мелкие части) код на функции, чем SQL...блоки SQL?
У вас есть 4 веб-сервера и куча приложений для Windows, которые используют один и тот же SQL-код, Теперь вы поняли, что есть небольшая проблема с SQl-кодом, так что сделайте это скорее......измените процедуру в 1 месте или отправьте код на все веб-серверы, переустановите все настольные приложения (может помочь clickonce) во всех окнах Windows
Почему ваши приложения для Windows подключаются напрямую к центральной базе данных?Это кажется ОГРОМНОЙ дырой в безопасности и узким местом, поскольку исключает кэширование на стороне сервера.Разве они не должны подключаться через веб-службу или что-то подобное к вашим веб-серверам?
Итак, нажимаем 1 новый sproc или 4 новых веб-сервера?
В данном случае это является проще запустить один новый sproc, но, по моему опыту, 95% "внесенных изменений" влияют на код, а не на базу данных.Если вы отправляете 20 данных на веб-серверы в этом месяце и 1 в базу данных, вы вряд ли много потеряете, если вместо этого отправите 21 информацию на веб-серверы и ноль в базу данных.
Более легкий анализ кода.
Можете ли вы объяснить, как это произошло?Я этого не понимаю.Особенно учитывая, что sprocs, вероятно, не находятся в системе управления версиями и, следовательно, не могут быть доступны через веб-браузеры SCM и так далее.
Еще больше минусов:
Хранимые процедуры хранятся в базе данных, которая представляется внешнему миру как черный ящик.Простые вещи, такие как желание поместить их в систему управления версиями, превращаются в кошмар.
Существует также проблема огромных усилий.Возможно, имело бы смысл разбить все на миллион уровней если вы пытаетесь оправдаться перед своим генеральным директором, почему создание нескольких форумов обошлось им всего в 7 миллионов долларов, но в остальном создание storedproc для каждой мелочи - это просто дополнительная рутинная работа без какой-либо выгоды.
Другие советы
В настоящее время это обсуждается в нескольких других темах здесь.Я последовательный сторонник хранимых процедур, хотя приводятся некоторые веские аргументы в пользу Linq to Sql.
Встраивание запросов в ваш код тесно привязывает вас к вашей модели данных.Хранимые процедуры являются хорошей формой контрактного программирования, означающей, что администратор базы данных имеет свободу изменять модель данных и код в процедуре до тех пор, пока сохраняется контракт, представленный входными данными и выходными данными хранимой процедуры.
Настройка производственных баз данных может быть чрезвычайно сложной задачей, когда запросы скрыты в коде, а не в одном центральном месте, которым легко управлять.
[Редактировать] Вот еще один текущее обсуждение
На мой взгляд, вы не можете голосовать за "да" или "нет" по этому вопросу.Это полностью зависит от дизайна вашего приложения.
Я категорически голосую против использования SPS в трехуровневой среде, где у вас есть сервер приложений впереди.В такой среде ваш сервер приложений предназначен для запуска вашей бизнес-логики.Если вы дополнительно используете SPs, вы начинаете распространять свою реализацию бизнес-логики по всей вашей системе, и становится очень неясно, кто за что отвечает.В конечном итоге вы получите сервер приложений, который в основном не будет делать ничего, кроме следующего:
(Pseudocode)
Function createOrder(Order yourOrder)
Begin
Call SP_createOrder(yourOrder)
End
Итак, в итоге у вас есть свой средний уровень, работающий на этом очень крутом кластере из 4 серверов, каждый из которых оснащен 16 процессорами, и он фактически вообще ничего не будет делать!Какая пустая трата времени!
Если у вас есть толстый клиент с графическим интерфейсом, который напрямую подключается к вашей базе данных или, возможно, даже к большему количеству приложений, это совсем другая история.В этой ситуации SPS может служить своего рода псевдо-средним уровнем, который отделяет ваше приложение от модели данных и предлагает контролируемый доступ.
Преимущества для встроенного кода:
- Проще в обслуживании - не нужно запускать SQL-скрипт для обновления запросов.
- Проще перенести в другую базу данных - нет процедур для переноса
На самом деле, я думаю, у вас все наоборот.ИМХО, SQL в коде - это боль в обслуживании, потому что:
- в конечном итоге вы повторяетесь в связанных блоках кода
- SQL не поддерживается как язык во многих IDE, поэтому у вас есть только ряд строк, не проверенных на ошибки, выполняющих задачи за вас
- изменения в типе данных, имени таблицы или ограничении встречаются гораздо чаще, чем замена всей базы данных на новую
- ваш уровень сложности возрастает по мере усложнения вашего запроса
- а тестирование встроенного запроса требует создания проекта
Думайте о сохраненных процедурах как о методах, которые вы вызываете из объекта базы данных - их намного проще использовать повторно, есть только одно место для редактирования, и в случае, если вы меняете поставщиков БД, изменения происходят в ваших сохраненных процедурах, а не в вашем коде.
Тем не менее, прирост производительности хранимых процедур минимален, как сказал Стю до меня, и вы не можете установить точку останова в хранимой процедуре (пока).
CON
Я нахожу, что выполнение большого объема обработки внутри хранимых процедур сделало бы ваш сервер БД единственной точкой негибкости, когда дело доходит до масштабирования вашего действия.
Однако выполнение всего этого в вашей программе, в отличие от sql-сервера, мог бы позволяет вам масштабировать больше, если у вас есть несколько серверов, на которых выполняется ваш код.Конечно, это относится не к сохраненным процедурам, которые выполняют только обычную выборку или обновление, а к тем, которые выполняют больше обработки, например, перебор наборов данных.
ПЛЮСЫ
- Производительность, какой бы она ни была (позволяет избежать разбора запросов драйвером БД / планом восстановления и т.д.)
- Манипулирование данными не встроено в код C / C ++ / C #, что означает, что у меня меньше низкоуровневого кода для просмотра.SQL менее подробный, и его легче просматривать, если он указан отдельно.
- Благодаря разделению пользователи могут намного проще находить и повторно использовать SQL-код.
- Проще что-то менять при изменении схемы - вам просто нужно предоставить тот же результат коду, и он будет работать просто отлично
- Проще перенести в другую базу данных.
- Я могу перечислить индивидуальные разрешения для своих хранимых процедур и контролировать доступ также на этом уровне.
- Я могу профилировать свой код запроса / сохранения данных отдельно от моего кода преобразования данных.
- Я могу реализовать изменяемые условия в своей хранимой процедуре, и это было бы легко настроить на сайте заказчика.
- Становится проще использовать некоторые автоматизированные инструменты для совместного преобразования моей схемы и операторов, а не когда это встроено в мой код, где мне пришлось бы выискивать их.
- Обеспечение наилучших методов доступа к данным проще, когда у вас есть весь ваш код доступа к данным внутри одного файла - я могу проверить наличие запросов, которые обращаются к неэффективной таблице или к таблице, использующей более высокий уровень сериализации или select * в коде и т.д.
- Становится легче находить изменения схемы / логики манипулирования данными, когда все это перечислено в одном файле.
- Становится проще выполнять поиск и заменять правки в SQL, когда они находятся в одном и том же месте, напримеризмените / добавьте инструкции изоляции транзакций для всех сохраненных процедур.
- Я и парень из DBA считаем, что иметь отдельный файл SQL проще / удобнее, когда DBA должен просматривать мои материалы SQL.
- Наконец, вам не нужно беспокоиться об атаках с использованием SQL-инъекций, потому что какой-то ленивый член вашей команды не использовал параметризованные запросы при использовании встроенных sqll.
Преимущество в производительности хранимых процедур часто незначительно.
Дополнительные преимущества хранимых процедур:
- Предотвратить обратное проектирование (если оно создано с использованием шифрования, конечно)
- Улучшенная централизация доступа к базе данных
- Возможность прозрачного изменения модели данных (без необходимости развертывания новых клиентов);особенно удобно, если несколько программ обращаются к одной и той же модели данных
Я падаю на код сбоку.Мы создаем уровень доступа к данным, который используется всеми приложениями (как веб-, так и клиентскими), так что с этой точки зрения он ПРОСТ.Это упрощает развертывание базы данных, потому что нам просто нужно убедиться, что схема таблицы верна.Это упрощает обслуживание кода, потому что нам не нужно смотреть на исходный код и базу данных.
У меня нет особых проблем с тесной связью с моделью данных, потому что я не вижу, где можно действительно разорвать эту связь.Приложение и его данные по своей сути взаимосвязаны.
Хранимые процедуры.
Если проскальзывает ошибка или логика немного меняется, вам не нужно перекомпилировать проект.Кроме того, он обеспечивает доступ из разных источников, а не только из одного места, где вы закодировали запрос в своем проекте.
Я не думаю, что поддерживать хранимые процедуры сложнее, вы должны сначала кодировать их не непосредственно в базе данных, а в отдельных файлах, затем вы можете просто запускать их в любой базе данных, которую вам нужно настроить.
Преимущества хранимых процедур:
Более легкий анализ кода.
Менее сопряженный, следовательно, более легко тестируемый.
Более легко настраивается.
Производительность, как правило, лучше с точки зрения сетевого трафика - если у вас есть курсор или что-то подобное, то нет многократных обращений к базе данных
Вы можете более легко защитить доступ к данным, удалить прямой доступ к таблицам, обеспечить безопасность с помощью процедур - это также позволяет вам относительно быстро находить любой код, который обновляет таблицу.
Если задействованы другие службы (например, службы Reporting services), вам может оказаться проще хранить всю вашу логику в хранимой процедуре, а не в коде и дублировать его
Недостатки:
Разработчикам сложнее управлять:контроль версий скриптов:у каждого ли есть своя база данных, интегрирована ли система контроля версий с базой данных и IDE?
В некоторых случаях динамически созданный sql в коде может иметь лучшую производительность, чем хранимый процесс.Если вы создали сохраненный процесс (скажем, sp_customersearch), который становится чрезвычайно сложным с десятками параметров, потому что он должен быть очень гибким, вы, вероятно, можете сгенерировать гораздо более простой sql-оператор в коде во время выполнения.
Можно было бы возразить, что это просто переносит некоторую обработку с SQL на веб-сервер, но в целом это было бы хорошо.
Другая замечательная особенность этого метода заключается в том, что если вы смотрите в SQL profiler, вы можете увидеть сгенерированный вами запрос и отладить его намного проще, чем видеть, как поступает сохраненный вызов proc с 20 параметрами.
Мне нравятся хранимые процедуры, не знаю, сколько раз мне удавалось вносить изменения в приложение, используя хранимую процедуру, которая не приводила к простою приложения.
Большой поклонник Transact SQL, настройка больших запросов оказалась для меня очень полезной.Я не писал ни одного встроенного SQL примерно 6 лет!
Вы перечисляете 2 плюса для sprocs:
Производительность - не совсем.В Sql 2000 или более поздней версии оптимизация плана запросов довольно хороша и кэшируется.Я уверен, что Oracle и т.д. делают подобные вещи.Я не думаю, что у sprocs больше есть основания для повышения производительности.
Безопасность?Почему sprocs должны быть более безопасными?Если у вас все равно нет довольно незащищенной базы данных, весь доступ будет осуществляться из вашей базы данных или через ваше приложение.Всегда параметризуйте все запросы - никогда не вставляйте что-либо из пользовательского ввода, и все будет в порядке.
В любом случае, это лучшая практика для повышения производительности.
Linq - это определенно тот путь, которым я бы сейчас занялся в новом проекте.Видишь это похожий пост.
@Кит
Безопасность?Почему sprocs должны быть более безопасными?
Как предложил Komradekatz, вы можете запретить доступ к таблицам (для комбинации имя пользователя / пароль, которая подключается к БД) и разрешить доступ только к SP.Таким образом, если кто-то получит имя пользователя и пароль к вашей базе данных, он сможет выполнить SP, но не сможет получить доступ к таблицам или любой другой части базы данных.
(Конечно, выполнение sprocs может предоставить им все необходимые данные, но это будет зависеть от доступных sprocs.Предоставление им доступа к таблицам дает им доступ ко всему.)
Подумайте об этом с такой точки зрения
У вас есть 4 веб-сервера и куча приложений для Windows, которые используют один и тот же SQL-код Теперь вы поняли, что есть небольшая проблема с SQl-кодом поэтому вы скорее......измените процедуру в 1 месте или отправьте код на все веб-серверы, переустановите все настольные приложения (может помочь clickonce) во всех окнах Windows
Я предпочитаю хранимые процедуры
Также проще выполнить тестирование производительности с помощью proc, поместить его в query analyzer установите statistics io / time включенным установите showplan_text включенным и вуаля
нет необходимости запускать профилировщик, чтобы точно увидеть, что вызывается
всего лишь мои 2 цента
Я предпочитаю хранить их в коде (используя ORM, а не встроенный или ad-hoc), чтобы они были охвачены системой управления версиями без необходимости сохранения .sql-файлы.
Кроме того, хранимые процедуры по своей сути не являются более безопасными.Вы можете написать неверный запрос с помощью sproc так же легко, как и встроенный.Параметризованные встроенные запросы могут быть такими же безопасными, как и sproc.
Используйте код вашего приложения так, как он делает лучше всего:обрабатывайте логику.
Используйте свою базу данных для того, что она делает лучше всего:храните данные.
Вы можете отлаживать хранимые процедуры, но вам будет проще отлаживать и поддерживать логику в коде.Обычно вы заканчиваете перекомпиляцию своего кода каждый раз, когда меняете модель базы данных.
Кроме того, хранимые процедуры с необязательными параметрами поиска очень неэффективны, потому что вы должны заранее указать все возможные параметры, а сложный поиск иногда невозможен, потому что вы не можете предсказать, сколько раз параметр будет повторяться в seach.
Когда дело доходит до безопасности, хранимые процедуры гораздо более безопасны.Некоторые утверждают, что весь доступ в любом случае будет осуществляться через приложение.Вещь, о которой многие люди забывают, заключается в том, что большинство нарушений безопасности происходят внутри компании.Подумайте о том, сколько разработчиков знают "скрытое" имя пользователя и пароль для вашего приложения?
Кроме того, как отметил Маттиуф, производительность может быть значительно улучшена за счет меньшего количества обходов между приложением (будь то на настольном компьютере или веб-сервере) и сервером базы данных.
По моему опыту, абстракция модели данных с помощью хранимых процедур также значительно улучшает ремонтопригодность.Как человек, которому в прошлом приходилось поддерживать множество баз данных, я испытываю такое облегчение, когда сталкиваюсь с необходимостью изменения модели, что могу просто изменить одну-две хранимые процедуры и сделать это изменение полностью прозрачным для ВСЕХ внешних приложений.Часто ваше приложение не единственное, которое указывает на базу данных - существуют другие приложения, решения для создания отчетов и т.д.таким образом, отслеживание всех этих затронутых точек может оказаться непростой задачей при открытом доступе к таблицам.
Я также поставлю галочки в колонке "Плюс" для того, чтобы передать SQL-программирование в руки тех, кто в нем специализируется, и для SPS, которые значительно упрощают изоляцию и тестирование / оптимизацию кода.
Единственным недостатком, который я вижу, является то, что многие языки не допускают передачу параметров таблицы, поэтому передача неизвестных числовых значений данных может раздражать, а некоторые языки по-прежнему не могут обрабатывать получение нескольких наборов результатов из одной хранимой процедуры (хотя последнее в этом отношении не делает SPS хуже встроенного SQL).
Одно из предложений, сделанных на технических сессиях Microsoft по безопасности, на которых я присутствовал, заключалось в том, чтобы совершать все вызовы через сохраненные процедуры и запрещать доступ непосредственно к таблицам.Такой подход был заявлен как обеспечивающий дополнительную безопасность.Я не уверен, стоит ли это того только из соображений безопасности, но если вы уже используете хранимые процедуры, это не повредит.
Определенно, его будет проще поддерживать, если вы поместите его в хранимую процедуру.Если задействована сложная логика, которая потенциально может измениться в будущем, определенно хорошей идеей будет поместить ее в базу данных, когда у вас подключается несколько клиентов.Например, прямо сейчас я работаю над приложением, у которого есть веб-интерфейс конечного пользователя и административное настольное приложение, оба из которых совместно используют базу данных (очевидно), и я пытаюсь сохранить как можно больше логики в базе данных.Это прекрасный пример того, как СУХОЙ принцип.
Я твердо стою на стороне хранимых процедур, предполагая, что вы не жульничаете и не используете динамический SQL в хранимых процедурах.Во-первых, использование хранимых процедур позволяет администратору базы данных устанавливать разрешения на уровне хранимых процедур, а не на уровне таблицы.Это важно не только для борьбы с атаками SQL-инъекций, но и для предотвращения прямого доступа инсайдеров к базе данных и внесения изменений.Это способ помочь предотвратить мошенничество.Доступ к базе данных, содержащей личную информацию (SSN, номера кредитных карт и т.д.) или которая в любом случае создает финансовые транзакции, никогда не должен осуществляться иначе, как с помощью строгих процедур.Если вы используете любой другой метод, вы оставляете свою базу данных широко открытой для отдельных сотрудников компании для создания поддельных финансовых транзакций или кражи данных, которые могут быть использованы для кражи личных данных.
Сохраненные процедуры также намного проще поддерживать и настраивать производительность, чем SQL, отправляемый из приложения.Они также позволяют администратору базы данных видеть, какое влияние структурные изменения базы данных окажут на способ доступа к данным.Я никогда не встречал хорошего администратора базы данных, который разрешил бы динамический доступ к базе данных.
Мы используем хранимые процедуры с Oracle DB, где я сейчас работаю.Мы также используем Subversion.Все хранимые процедуры создаются в виде файлов .pkb и .pks и сохраняются в Subversion.Я уже делал встроенный SQL раньше, и это настоящая боль!Мне гораздо больше нравится то, как мы делаем это здесь.Создавать и тестировать новые хранимые процедуры намного проще, чем делать это в вашем коде.
Тереза
Бревна меньшего размера
Еще один незначительный плюс хранимых процедур, который не был упомянут:когда дело доходит до трафика SQL, доступ к данным на основе sp генерирует многое меньше пробок.Это становится важным, когда вы отслеживаете трафик для анализа и профилирования - журналы будут намного меньше и удобочитаемы.
Я не большой поклонник хранимых процедур, но я использую их при одном условии:
Когда запрос довольно большой, лучше сохранить его в базе данных в виде хранимой процедуры, а не отправлять из кода.Таким образом, вместо отправки огромного количества строковых символов с сервера приложений в базу данных, только "EXEC SPNAME" команда будет отправлена.
Это излишне, когда сервер базы данных и веб-сервер не находятся в одной сети (например, для связи через Интернет).И даже если это не так, слишком сильный стресс означает большую потерю пропускной способности.
Но, черт возьми, ими так ужасно управлять.Я избегаю их, насколько могу.
Процедура, сохраненная в SQL, не повышает производительность запроса
Что ж, очевидно, что использование хранимых процедур имеет ряд преимуществ по сравнению с построением SQL в коде.
- Ваша реализация кода и SQL становятся независимыми друг от друга.
- Код легче читается.
- Пишите один раз, используйте много раз.
- Изменить один раз
- Нет необходимости сообщать программисту внутренние данные о базе данных.и т.д., и т.п.
Хранимые процедуры - это Еще ремонтопригоден, потому что:
- Вам не нужно перекомпилировать ваше приложение на C # всякий раз, когда вы хотите изменить какой-либо SQL
- В конечном итоге вы повторно используете SQL-код.
Повторение кода - это худший вот что вы можете сделать, когда пытаетесь создать поддерживаемое приложение!
Что происходит, когда вы обнаруживаете логическую ошибку, которую необходимо исправить в нескольких местах?Вы скорее всего забудете изменить то последнее место, куда вы скопировали и вставили свой код.
На мой взгляд, повышение производительности и безопасности является дополнительным плюсом. Вы все еще можете писать небезопасные / неэффективные хранимые процедуры SQL.
Проще перенести в другую базу данных - нет процедур для переноса
Не очень сложно прописать все ваши хранимые процедуры для создания в другой базе данных.На самом деле - это легче чем экспортировать ваши таблицы, потому что нет первичных / внешних ключей, о которых нужно беспокоиться.
@Terrapin - sprocs так же уязвимы для инъекционных атак.Как я уже сказал:
Всегда параметризуйте все запросы - никогда не вставляйте что-либо из пользовательского ввода, и все будет в порядке.
Это относится к sprocs и динамическому Sql.
Я не уверен, что отказ от перекомпиляции вашего приложения является преимуществом.Я имею в виду, что вы все равно запустили свои модульные тесты против этого кода (как приложения, так и базы данных), прежде чем снова начать работу.
@Guy - да, вы правы, sprocs действительно позволяют вам управлять пользователями приложения, чтобы они могли выполнять только sproc, а не базовое действие.
Мой вопрос был бы таким:если все получают к нему доступ через ваше приложение, используя подключения и пользователей с ограниченными правами на обновление / вставку и т.д., добавляет ли этот дополнительный уровень безопасности или дополнительного администрирования?
Мое мнение во многом придерживается последнего.Если они скомпрометировали ваше приложение до такой степени, что могут переписать его заново, у них есть множество других атак, которые они могут использовать.
Sql-инъекции все еще могут быть выполнены против этих sprocs, если они динамически встроены в код, поэтому по-прежнему применяется золотое правило: весь пользовательский ввод всегда должен быть параметризован.
Кое-что, о чем я до сих пор не упоминал:люди, которые лучше всего знают базу данных, не всегда являются теми людьми, которые пишут код приложения.Хранимые процедуры дают специалистам по базам данных возможность взаимодействовать с программистами, которые на самом деле не хотят так много знать о SQL.Большие - и особенно устаревшие - базы данных - это не самые простые вещи для полного понимания, поэтому программисты могут просто предпочесть простой интерфейс, который дает им то, что им нужно:пусть администраторы баз данных разберутся, как объединить 17 таблиц, чтобы это произошло.
При этом языки, используемые для написания хранимых процедур (печально известный пример - PL / SQL), довольно жестокие.Обычно они не предлагают никаких тонкостей, которые вы могли бы увидеть в популярных сегодня императивных, ООП или функциональных языках.Подумай о КОБОЛЕ.
Итак, придерживайтесь хранимых процедур, которые просто абстрагируются от реляционных деталей, а не от тех, которые содержат бизнес-логику.
Обычно я пишу OO-код.Я подозреваю, что большинство из вас, вероятно, тоже так думают.В этом контексте мне кажется очевидным, что вся бизнес-логика, включая SQL-запросы, принадлежит определениям классов.Разделить логику таким образом, чтобы часть ее находилась в объектной модели, а часть - в базе данных, ничуть не лучше, чем поместить бизнес-логику в пользовательский интерфейс.
В предыдущих ответах много говорилось о преимуществах безопасности хранимых процедур.Они делятся на две широкие категории:
1) Ограничение прямого доступа к данным.Это определенно важно в некоторых случаях, и, когда вы сталкиваетесь с таким, сохраненные процедуры в значительной степени являются вашим единственным вариантом.Однако, по моему опыту, подобные случаи являются скорее исключением, чем правилом.
2) SQL-инъекция / параметризованные запросы.Это возражение - отвлекающий маневр.Встроенный SQL - даже динамически генерируемый встроенный SQL - может быть так же полностью параметризован, как и любая хранимая процедура, и это может быть сделано так же легко на любом современном языке, заслуживающем внимания.Здесь нет никакого преимущества в любом случае.("Ленивые разработчики могут не утруждать себя использованием параметров" - это необоснованное возражение.Если в вашей команде есть разработчики, которые предпочитают просто объединять пользовательские данные в свой SQL вместо использования параметров, вы сначала пытаетесь обучить их, а затем увольняете, если это не работает, точно так же, как вы бы поступили с разработчиками, у которых есть любая другая плохая, явно пагубная привычка.)
Я большой сторонник code, а не SPROC.Причина номер один заключается в том, что код остается тесно связанным, а вторая - в простоте управления версиями без множества пользовательских утилит для его использования.
В нашем DAL, если у нас есть очень сложные инструкции SQL, мы обычно включаем их в качестве файлов ресурсов и обновляем их по мере необходимости (это также может быть отдельная сборка, которая заменяется для каждой базы данных и т.д.).
Это позволяет сохранить наш код и наши sql-вызовы в одном и том же элементе управления версиями, не "забывая" запускать некоторые внешние приложения для обновления.
