Это определенно помогло бы, если бы в вопросе содержались некоторые измерения неоптимизированного решения (размеры данных, время).Здесь можно рассмотреть различные методы, некоторые из которых перечислены в других ответах.Я предполагаю, что причиной, по которой вы не хотите выполнять один и тот же запрос несколько раз, является производительность.
Если все случаи использования набора кэшированных идентификаторов состоят из объединений всего набора с дополнительными таблицами, решение должноопределенно не включать кэширование набора идентификаторов за пределами базы данных.Данные не должны перемещаться туда и обратно, если вы можете их избежать.
В некоторых случаях (когда не задействованы курсоры или чрезвычайно сложный SQL), может быть лучше (даже если это противоречит интуиции) не выполнять кэширование и просто присоединятьсяповторяющийся SQL для всех желаемых запросов.В конце концов, каждый запрос должен проходить по одной из соединенных таблиц, и тогда производительность в значительной степени зависит от доступности индексов, необходимых для быстрого объединения и оценки всей оставшейся информации.
Наиболее интуитивный подходдля «кэширования» набор идентификаторов в базе данных представляет собой временную таблицу (если она названа #something, она является частной для соединения и поэтому может использоваться параллельными независимыми клиентами; или она может называться ##something и быть глобальной).Если в таблице будет много записей, необходимы индексы.Для достижения оптимальной производительности индекс должен быть кластеризованным (допускается только один для каждой таблицы) или создаваться только после создания этого набора, где создание индекса выполняется немного быстрее.
Индексированные представления предпочтительнее временных таблиц, за исключениемкогда базовые данные читаются только в течение всего процесса или когда вы можете и хотите игнорировать такие обновления, чтобы сохранить весь набор отчетов непротиворечивым, насколько этот набор идет.Однако способность индексированных представлений всегда точно проецировать базовые данные обуславливает замедление этих обновлений.
В другом ответе на этот вопрос упоминаются хранимые процедуры.Это в значительной степени способ организации вашего кода.Однако, если вы идете по этому пути, предпочтительно избегать использования временных таблиц, поскольку такие ссылки на временную таблицу предотвращают предварительную компиляцию хранимой процедуры;если возможно, переходите к представлениям или индексированным представлениям.
Независимо от выбранного вами подхода не угадывайте характеристики производительности и поведение оптимизатора запросов.Научитесь отображать планы выполнения запросов (в SQL Server Management Studio) и убедитесь, что вы видите доступ к индексу, а не вложенные циклы, объединяющие несколько больших наборов данных;добавляйте только те индексы, которые наглядно и радикально изменят производительность ваших запросов.Правильно выбранный индекс часто может изменить производительность запроса в 1000 раз, поэтому его довольно сложно изучить, но важно для успеха.
И, наконец, что не менее важно, обязательно используйте UPDATE STATISTICS, когдаперезаполнение базы данных (и каждую ночь в производстве), иначе ваш оптимизатор запросов не сможет использовать созданные вами индексы наилучшим образом.