Зачем мне нужны хранимые процедуры, когда у меня есть LINQ to SQL

Question

Насколько я понимаю, Linq to Sql возьмет мой оператор Linq и преобразует его в эквивалентный оператор SQL.

Так

var products = from p in db.Products
               where p.Category.CategoryName == "Beverages"
               select p

Просто превращается в

Select * from Products where CategoryName = 'Beverages'

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

Answer 1

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

Answer 2

если это все, что вы когда-либо делали в sql, вам раньше не нужны были sprocs!

Answer 3

Security.

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

Я никогда лично не работал над проектом, который работал таким образом, он всегда казался гигантской болью в задней части.

Answer 4

Ах, предмет многих дебатов.

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

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

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

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

Answer 5

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

1. упрощает настройку безопасности (как упоминалось другими авторами).
2. Он предоставляет четко определенный интерфейс для доступа к БД (хотя ответственность за это может быть перенесена на другие области, такие как DAL, написанный на C #
3. Я считаю, что Оптимизатор запросов, по крайней мере в Oracle, способен принимать более разумные решения, чем больше информации вы ему предоставляете. Это действительно требует тестирования с обоими методами, хотя для ваших конкретных сценариев.
4. В зависимости от доступных разработчиков, у вас могут быть очень хорошие кодеры SQL, которые будут лучше создавать эффективные запросы, если они используют sprocs.

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

Answer 6

1. Хранимые процедуры и Linq to Sql решают различные проблемы.

2. Linq to Sql относится к Microsoft SQL Server.

Answer 7

Я могу придумать несколько веских причин для хранимых процедур:

• При работе с большими таблицами может быть сложно создать эффективный запрос, используя LINQ to SQL.
• Администратор БД может анализировать и выявлять проблемы хранимых процедур. Но подумайте о том, что происходит, когда сталкиваются две сложные операции LINQ из разных внешних интерфейсов.
• Хранимые процедуры могут обеспечить целостность данных. Запретить запись в таблицы и разрешить изменения только с помощью хранимой процедуры.
• Обновление хранимых процедур так же просто, как запуск ALTER PROCEDURE на сервере. Если развертывание занимает месяцы, а сценарий - минуты, вы будете более гибкими в использовании хранимых процедур.

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

Answer 8

Существуют значительные улучшения производительности на стороне SQL Server, если вы используете хранимые процедуры в соответствующих обстоятельствах.

Answer 9

Поддержка хранимых процедур для LINQ to SQL была включена частично для совместимости с существующими системами. Это позволяет разработчикам переходить от системы на основе sproc к полностью основанной на LINQ системе с течением времени, sproc by sproc, вместо того, чтобы заставлять разработчиков стремиться конвертировать всю систему сразу.

Answer 10

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