S>Ошибка уже здесь. Временная таблица — это очень плохое решение:

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

Кроме того, из БД нужно выбрать и аналоги и упаковки для одного и того же списка товаров.
То есть все равно придется выполнить два запроса. Значит, список товаров должен быть каким-то образом быть "общим".
Поэтому мне кажется, что все-таки лучше этот список товаров предварительно положить куда-то на sql-сервер, чтобы затем выполнить эти два запроса, использующие этот "общий" список товаров.
Зачем его дважды гонять туда-сюда на сервер?
Куда его положить, кроме как во временную таблицу?

S>1. Если несколько пользователей выполняют запросы одновременно, то их результаты перемешаются во временной таблице. Это можно решить, но потребуется набор костылей.

Наверно это можно решить добавлением нового поля во временную таблицу типа "ID_сессии".

S>... Выполнение поиска аналогов как единого запроса позволяет СУБД построить оптимальный план ...

А как это — "единый запрос"?

S>Лучше всего — работать с системой, которая позволяет манипулировать с запросами как с запросами.
S>Например, на linq:
S>var tovarList = TovarRepository.GetList(filterCritery); // никакого обращения в базу ещё нет, просто построен запрос.
S>/// запрос устроен так, что при его исполнении в базу поедет что-то вроде select * from tovar where ...
S>var analogList = AnalogRepository.GetListByTovar(tovarList); // никакого обращения в базу ещё нет, просто построен запрос
S>/// запрос устроен так, что при его исполнении в базу поедет что-то вроде select * from tovar where SELECT * FROM analogs WHERE analog.tovar_id IN (select * from tovar where ...)

Я читал про linq, но по сути не знаю.
Если про вызове функций репозиториев "GetList" формируются только запросы, то в какой момент они выполняются?
По какой-то отдельной команде?

Так как у меня sqlite, я весь код для работы с БД пишу сам "вручную": и слой Репозиториев и слой DataAccess.
Поэтому можно попробовать сделать так, чтобы "мои" репозитории тоже манипулировали запросами. Главное понять принцип как это все должно работать.

S>Если не получается прикрутить ленивые запросы с возможностями подстановки друг в друга ...

Ленивые запросы — это и есть "отложенное" манипулирование запросами?

S>... то можно обойтись простым вариантом, в котором AnalogRepository при построении GetListByTovars(IEnumerable<Tovar>) просто берёт и строит список ID переданных ему товаров: SELECT * FROM analogs WHERE analog.tovar_id IN (4, 8, 15, 16, 23, 42)
S>Здесь нет никакой временной таблицы и связанных с ней проблем.

А если список товаров очень большой? ID-шники задаются в виде GUID-ов, то есть очень длинные.
Строка запроса по списку 1000 товаров превысит все допустимые размеры.

S>Ошибка уже здесь. Временная таблица — это очень плохое решение:

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

Кроме того, из БД нужно выбрать и аналоги и упаковки для одного и того же списка товаров.
То есть все равно придется выполнить два запроса. Значит, список товаров должен каким-то образом быть "общим".
Поэтому мне кажется, что все-таки лучше этот список товаров предварительно положить куда-то на sql-сервер, чтобы затем выполнить эти два запроса, использующие этот "общий" список товаров.
Зачем его дважды гонять туда-сюда на сервер?
Куда его положить, кроме как во временную таблицу?

S>1. Если несколько пользователей выполняют запросы одновременно, то их результаты перемешаются во временной таблице. Это можно решить, но потребуется набор костылей.

Наверно это можно решить добавлением нового поля во временную таблицу типа "ID_сессии".

S>... Выполнение поиска аналогов как единого запроса позволяет СУБД построить оптимальный план ...

А как это — "единый запрос"?

S>Лучше всего — работать с системой, которая позволяет манипулировать с запросами как с запросами.
S>Например, на linq:
S>var tovarList = TovarRepository.GetList(filterCritery); // никакого обращения в базу ещё нет, просто построен запрос.
S>/// запрос устроен так, что при его исполнении в базу поедет что-то вроде select * from tovar where ...
S>var analogList = AnalogRepository.GetListByTovar(tovarList); // никакого обращения в базу ещё нет, просто построен запрос
S>/// запрос устроен так, что при его исполнении в базу поедет что-то вроде select * from tovar where SELECT * FROM analogs WHERE analog.tovar_id IN (select * from tovar where ...)

Я читал про linq, но по сути не знаю.
Если при вызове функций репозиториев "GetList" формируются только запросы, то в какой момент они выполняются?
По какой-то отдельной команде?

Так как у меня sqlite, я весь код для работы с БД пишу сам "вручную": и слой Репозиториев и слой DataAccess.
Поэтому можно попробовать сделать так, чтобы "мои" репозитории тоже манипулировали запросами. Главное понять принцип как это все должно работать.

S>Если не получается прикрутить ленивые запросы с возможностями подстановки друг в друга ...

Ленивые запросы — это и есть "отложенное" манипулирование запросами?

S>... то можно обойтись простым вариантом, в котором AnalogRepository при построении GetListByTovars(IEnumerable<Tovar>) просто берёт и строит список ID переданных ему товаров: SELECT * FROM analogs WHERE analog.tovar_id IN (4, 8, 15, 16, 23, 42)
S>Здесь нет никакой временной таблицы и связанных с ней проблем.

А если список товаров очень большой? ID-шники задаются в виде GUID-ов, то есть очень длинные.
Строка запроса по списку 1000 товаров превысит все допустимые размеры.