Любое преимущество хранимой процедуры * с * динамическим SQL внутри по сравнению с просто динамическим SQL C #?

Question

Вопрос

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

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

Поэтому я более склонен просто сделать это как динамический SQL внутри самого кода C # и пропустить сложность использования хранимой процедуры (и я чувствую, что на самом деле это будет больше читаемым в построенном C # up string), но это будет заметно медленнее, чем при использовании хранимой процедуры.

И для дополнительной интриги, является ли это областью, в которой EF будет на самом деле быстрее / такой же, как, разумеется, на самом деле все, что он делает, это создает динамический SQL? (См. Справочную информацию)

Фон

Большая часть кода нашей базы данных написана с помощью хранимых процедур (как в 90%), но есть небольшая часть кода, написанная в Entity Framework. Меня попросили заменить EF хранимыми процедурами, поскольку эта область кода была определена как узкое место, и они хотят ее оптимизировать. Как фанат EF, я хочу отодвинуть оптимальную точку, но как фанат последовательности я изначально не видел никакой причины не согласовывать эти 10% с другими 90% .... теперь я делаю, операция речь идет о подкачке страниц и динамической сортировке!

Answer 1

Преимущества

Преимущества SQL в хранимой процедуре:

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

Downsides

Недостатки динамического SQL в хранимых процедурах:

Динамический SQL (на сервере SQL) может быть сложен с безопасностью и производительностью.

Безопасность

SQL-сервер имеет меньше «инструментов» для предотвращения внедрения. Переменные нельзя использовать повсеместно, и поэтому, если вы жестко закодируете весь порядок по опциям, тогда вы в безопасности. Но с динамической фильтрацией это может быть сложно.

например. это безопасно:

posts = context.Posts  
    .FromSql("SELECT * FROM mytable")
    .OrderByDescending(p => p.CreateDate)

Это небезопасно (да, есть лучшие способы написать это):

declare varchar(200) @orderby = 'createDate DESC'

SET @sqlCommand = 'SELECT * FROM mytable ORDER by + '@orderby

EXEC (@sqlCommand)

Так что вам нужно перечислить все опции или проверить все опции.

Производительность

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

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

Табличные значения функций

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

Они имеют преимущества хранимых процедур, как описано выше, но не имеют недостатков динамического SQL в базе данных!

См. https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/linq/how-to-use-table-valued-user-defined-functions

Пример TVF и EF Core

Есть хороший пример функций табличных значений и EF,

.NET Core с TFV GetMatchingPostByTitle

posts = context.Posts  
    .FromSql("SELECT * FROM dbo.GetMatchingPostByTitle({0})", searchTerm)
    .Where(p => p.BlogId == 1)
    .OrderByDescending(p => p.CreateDate)
    .ToList();

Сгенерирует этот SQL:

Подробнее здесь