Построение запроса по критерию множественного выбора

Question

Мне интересно, как другие будут обращаться с таким сценарием:

Скажем, у меня есть несколько вариантов выбора для пользователя.

Как, Цвет, Размер, Марка, Модель и т. Д.

Каково лучшее решение или практика для обработки построения вашего запроса для этого scneario?

, так что еслиони выбирают 6 из 8 возможных цветов, 4 из 7 возможных марок и 8 из 12 возможных брендов?

Вы можете делать динамические операторы OR или динамические операторы IN, но я пытаюсь выяснить, есть лилучшее решение для обработки этой логики критериев типа "ГДЕ"?

РЕДАКТИРОВАТЬ: я получаю действительно хорошие отзывы (спасибо всем) ... еще одна вещь, которую стоит отметить, что некоторые из выборов может быть дажекак (40 из возможных 46 возможных), так что довольно большой.Еще раз спасибо!

Спасибо,

S

Answer 1

То, что я хотел бы предложить сделать, - это создать функцию, которая будет принимать список makeIds, colorIds и т. Д. С разделителями. Вероятно, это будет int (или любой другой ключ).И разбивает их на таблицы для вас.

Ваш ИП примет список марок, цветов и т. Д., Как вы сказали выше.

YourSP '1,4,7,11', '1,6,7', '6' ....

Внутри вашего SP вы вызовете функцию разделения, которая будет возвращать таблицу -

SELECT * FROM
Cars C
JOIN YourFunction(@models) YF ON YF.Id = C.ModelId
JOIN YourFunction(@colors) YF2 ON YF2.Id = C.ColorId

Затем, если они ничего не выберут, они ничего не получат.Если они выберут все, они получат все.

Answer 2

Каково лучшее решение или практика для обработки сборки вашего запроса для этого сценария?

Динамический SQL.

Один параметр представляет два состояния - NULL / не существует или имеет значение. Еще два средства возводят в квадрат число параметров, чтобы получить количество полных возможностей: 2 - 4, 3 - 9 и т. Д. Один нединамический запрос может содержать все возможности, но между действиями будет работать ужасно:

1. ОШ
2. общая не проходимость
3. и невозможность повторного использования плана запроса

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

План запроса кэшируется в SQL Server 2005+, если вы используете команду sp_executesql - это не так, если вы используете только EXEC.

Я настоятельно рекомендую прочитать Проклятие и благословение динамического SQL .

Answer 3

Если вы хотите создать динамический SQL, не имеет значения, используете ли вы подход OR или IN.SQL Server будет обрабатывать операторы таким же образом (возможно, с небольшими изменениями в некоторых ситуациях.)

Вы также можете рассмотреть возможность использования временных таблиц для этого сценария.Вы можете вставить выборки для каждого критерия во временные таблицы (например, #tmpColor, #tmpSize, #tmpMake и т. Д.).Затем вы можете создать нединамический оператор SELECT.Может работать что-то вроде следующего:

SELECT <column list>
FROM MyTable
WHERE MyTable.ColorID in (SELECT ColorID FROM #tmpColor)
    OR MyTable.SizeID in (SELECT SizeID FROM #tmpSize)
    OR MyTable.MakeID in (SELECT MakeID FROM #tmpMake)

Динамические решения OR / IN и временные таблицы работают нормально, если каждое условие не зависит от других условий.Другими словами, если вам нужно выбрать строки, где ((цвет - красный, а размер - средний) или (цвет - зеленый, а размер - большой)), вам нужно попробовать другие решения.

Answer 4

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

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