Dimitry Sibiryakov,

Эта временная таблица нужна для ORM, когда у него получается запрос с большим количеством условий. Например, чтобы не городить гигантский запрос с where xxx in (...), он загоняет эти значения во временную таблицу и джойнит её с таблицей в запросе. На самом деле таких временных таблиц много. Есть временные таблицы для разных типов данных. И их по 10 штук для каждого типа данных на всякий случай.

Размер 256 был выбран хоть и "от балды", но после внимательного просмотра данных, которые могут участвовать в условиях при генерации запросов через ORM.

Шавлюк Евгений,

Не совсем понял. Таблица же временная. Заполнили, выполнили запрос, а при коммите она автоматом очистилась. Зачем там ещё "идентификатор сессии"?

Шавлюк Евгений,

У меня нету необходимости в "запрос выполнить в соседних окнах. И затем сравнить" ))

Я не понимаю какую тебе постановку надо. И этот антипатер я не делаю. Он давно уже сделан и работает.
Есть сервак с 3хзвенкой. На нём крутиться наш сервис. Сервис в качестве СУБД по желанию клиента может использовать разные СУБД, в том числе FB. Чаще всего с FB он и используется. Сервак многофункциональный. В том числе для него есть API, чтобы получать данные.
И данные, получаемые от сервиса, и условия запросов могут быть совершенно произвольными (но в рамках объектов ORM). Например: я хочу получить фамилии работников, которые обрабатывали материл по контролю за разработкой со скважин таких-то месторождений, в период такой-то. Или: выдай мне 3-мерные координаты пересечений пласта АС4 со стволами скважин, список скважин такой-то. Или: нужны результаты интерпретации скважин, в частности пористость, список скважин такой-то, список названий методов исследования такой-то ну и плюс дофига всяких вариантов, которые только можно напридумывать. Основной клиент, который пользуется этим сервисом - ещё одна система, которая у меня в организации и разрабатывается.
Причём ни одно значение в эту базу не вбивается вручную. Все данные попадают туда путём индексирования файлов-результатов работы большого количества работников. Этим индексированием тоже занимается наш сервис, который знает как парсить исходные файлы и как распихивать эту инфу по базе.
Просто недавно выяснилось, что количество параметров условий в запросе может быть очень большим (например при просмотре пользователями карты скважин больших месторождений). Из-за этого и был написан пост.

Так какие у тебя идеи как победить этот "антипатерн"? ))

Могут быть привязаны, могут быть не привязаны, могут быть привязаны хитрым образом. Всё зависит от того, как это было проиндексировано. Это не особо важно. Важно то, что прога, которая показывает карту (и которая частично для отображения карты использует наш сервис), просто запрашивает данные по куче скважин по их уникальному идентификатору, присвоенному нефтяной компанией. И не обязательно это будут скважины одного месторождения. Вроде как возможен вариант, когда на экране будут скважины с разных месторождений, если они умещаются на экране. Я сам не спец по этим картам, отвечаю только за работу с СУБД, индексирование и сетевой протокол для сервиса.

Dimitry Sibiryakov,

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

mayton,

Основной таблицы нету. Временная таблица может джойниться с любой таблицей из запроса, генерённого ORM, если по ней есть много условий. Мало того, может быть ситуация, когда используется дофига временных таблиц. Они заполняются и джойняться с разными таблицами из 100-этажного запроса. Тут как повезёт.

С этим я согласен на 146 процентов.


А вот с этим не согласен. На то они и временные таблицы, чтобы их заполнять данными и извращаться ради того, чтобы получить то, что тебе нужно ))


А вот это я совсем не понял. Что за динамические справочники и как они могут помочь.

mayton, ты лучше суть объясни того, что сказать хотел. А временные таблицы для строк конкретно под FB в моём случае создаются запросами типа

mayton,

Ты ничего не понял. Параллельно в разных транзакциях могут заполняться и использоваться и одни и те же временные таблицы. Например:
1-я транзакция использует TMP_S_0
2-я транзакция использует TMP_S_0, TMP_S_1, TMP_S_2, TMP_S_3, TMP_S_4, TMP_S_5 + временные таблицы для других типов данных
3-я транзакция использует TMP_S_0, TMP_S_1
4-й транзакции повезло, т.к. условий в запросе к сервису мало и все они влезли в текст SQL
5-я ... и т.д.

Вот так-то так. Причём в разных транзакциях джойн одной и той же временной таблицы может происходить с любой из реальных таблиц базы