Что вы посоветуете для реализации хранимых процедур SQL (в приложении C # winforms)?

Question

Я прочитал эти очень хорошие вопросы на SO о хранимых процедурах SQL:

• Когда следует использовать хранимые процедуры? и
• Являются ли хранимые процедуры в целом более эффективными, чем встроенные операторы современных СУБД?

Я новичок в интеграции .NET / SQL, хотя я использую базовые функции SQL более десяти лет в других средах. Пришло время продвинуться в отношении организации и развертывания. Я использую .NET C # 3.5, Visual Studio 2008 и SQL Server 2008; хотя этот вопрос можно рассматривать как независимый от языка и базы данных, то есть он может легко применяться к другим средам, в которых используются хранимые процедуры и реляционная база данных.

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

Вот некоторые дополнительные вопросы, связанные с этим вопросом, которые могут помочь сформировать ответы:

• Стоит ли создавать хранимые процедуры в SQL с помощью SQL Management Studio и просто заново создавать базу данных, когда она установлена ​​для клиента?
• Мне лучше создавать все хранимые процедуры в моем приложении внутри метода инициализации базы данных?
• Кажется логичным предположить, что создание хранимых процедур должно следовать за созданием таблиц в новой установке. Мой метод инициализации базы данных создает новые таблицы и вставляет некоторые данные по умолчанию. Я планирую создать хранимые процедуры после этого шага, но я начинаю думать, что может быть лучший способ создать базу данных с нуля (например, в установщике программы). Мысли об этом приветствуются.
• У меня есть множество запросов по всему приложению. Некоторые запросы невероятно просты (SELECT id FROM table), а другие очень длинные и сложные, выполняют несколько объединений и принимают около 80 параметров. Стоит ли заменять все запросы на хранимые процедуры или только те, которые могут извлечь выгоду из этого?
• Наконец, поскольку эта тема, очевидно, требует некоторых исследований и обучения, можете ли вы порекомендовать статью, книгу или учебное пособие, в которых рассматриваются нюансы использования хранимых процедур вместо прямых утверждений?

Answer 1

Попробуйте пропустить хранимые процедуры для ORM. Рассмотрите возможность использования:

• LINQ To SQL
• Entity Framework

• SubSonic

• Вы будете меньше писать код котельной плиты ListCustomer и GetCustomerByID, когда сможете добавить больше пользы к вашему приложению.

• IMO, нет никаких веских причин выбирать хранимые процедуры с современным набором инструментов, который есть у нас в стеке Microsoft.

• Отход от встроенных операторов SQL - это хорошо, и ORM поможет вам параметризировать ваши запросы. Вам не нужно об этом думать.

• Вам вообще не нужно связываться с объектами ADO.NET. Кодируйте свой доступ к данным объектно-ориентированным способом.

Answer 2

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

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

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

В качестве простого примера, ни таблицы, ни представления не могут быть параметризованы. Если у вас очень большая таблица или представление и вы хотите, чтобы все пользователи указывали определенный набор критериев фильтрации (например, дату моментального снимка или дату вступления в силу), это невозможно сделать в интерфейсе вызова базы данных. Фреймворк может отправлять запросы за все время. Если таблица / представление не отображается, и единственный интерфейс - через SP или табличную UDF, то должны быть предоставлены параметры для этого SP или UDF MUST , удовлетворяющие тем самым потребности вашей базы данных, чтобы гарантировать используется правильно.

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

Что касается сценариев создания схемы базы данных, включая объекты в правильном порядке зависимостей, для этого есть несколько инструментов (и генерируются сценарии изменений), в том числе Red Gate SQL Compare и Apex SQLScript.

Answer 3

Используйте хранимые процедуры, если у вас действительно есть требование к производительности, особенно если одна хранимая процедура будет вызываться тысячи раз в минуту. Таким образом, sql engine избегает нескольких шагов для обработки оператора. Системы слежения GPS являются примером. Скажем, у вас есть 10000 автомобилей, которые сообщают о 3 позициях в минуту. В этом случае хранимые процедуры помогают производительность.

Если нет, то вместо операторов CRUD SQL используйте функции ORM.

Answer 4

Вы пропустили один:

Когда лучше написать «ad hoc sql» против хранимых процедур

Мой ответ: вообще не использовать хранимые процедуры .