Рекомендации по минимизации параметров хранимых процедур

Question

У меня есть веб-приложение ASP.NET MVC, которое взаимодействует с базой данных SQL Server 2008 через Entity Framework 4.0.

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

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

Каждый из этих входов «сгруппирован» в логические секции.

Пример:

• Поле поиска: "Foo"
• Флажок А1: отмечен, Флажок А2: не отмечен
• Раскрывающийся список A: выбран вариант 3
• Флажок B1: отмечен, Флажок B2: отмечен, Флажок B3: не отмечен

Так что мне нужно вызвать SPROC следующим образом:

exec SearchPage_FindResults @SearchQuery = 'Foo', @IncludeA1 = 1, @IncludeA2 = 0, @DropDownSelection = 3, @IncludeB1 = 1, @IncludeB2 = 1, @IncludeB3 = 0

Интерфейс не слишком важен для этого вопроса - просто хотел дать некоторую перспективу.

По сути, я извлекаю результаты для поискового запроса, фильтруя эти результаты на основе набора (необязательных) вариантов, по которым пользователь может фильтровать.

Теперь Мои вопросы / запросы:

• Как лучше всего передать эти параметры хранимой процедуре?
• Есть ли какие-нибудь хитрости / новые способы (например, SQL Server 2008), чтобы сделать это? Специальные «таблицы» параметров / массивов - можем ли мы пройти через пользовательские типы? Имейте в виду, что я использую Entity Framework 4.0, но при необходимости всегда могу использовать классический ADO.NET для этого.
• А как насчет XML? Какова стоимость сериализации / десериализации здесь? Стоит ли это того?
• Как насчет параметра для каждого логического раздела? Возможно, через запятую? Просто мысли вслух.

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

С учетом сказанного - какой здесь лучший подход?

Answer 1

При быстром поиске в Google, похоже, что Entity Framework их не поддерживает, но вы можете использовать табличные параметры в ADO.

Вы можете управлять этим, определяя тип таблицы на своем сервере:

CREATE TYPE yourTypeName AS TABLE (
    columnName <column type>
    -- more columns if you wish, too
)

, а затем используйте его, создав SqlCommand и выполнив следующее:

SqlParameter param = command.CreateParameter();
param.ParameterName = "@something"
param.SqlDbType = SqlDbType.Structured
param.Value = // a DataTable which matches your table type, I can stick in code I use if you like
param.TypeName = "table type name";

И ваши процедуры будут выглядеть так:

CREATE PROCEDURE procName
@something yourTypeName READONLY
AS
BEGIN
...

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

С точки зрения производительности, я не администратор баз данных, и я не уверен, насколько быстр XML - я понимаю, он довольно быстрый.TVP, однако, работают довольно быстро, и даже относительно простой метод DataTable, который я использовал, работает отлично.Здесь есть больше о TVP здесь , и довольно много постов в блоге о SQL и TVP в целом.