fd00chесли у меня двухзвенка и лаг между клиентом и сервером 100 мс - как максимально быстро создать эту временную таблицу из хотя бы 10 тыс строк?
Ты в любом случае не сможешь её создать быстрее, чем пользователь тыкает в мышкой. А он это делает реже чем пять раз в секунду, так что делай запросы в отдельном потоке и задержек никто не заметит.

NickDeeУ некоторых моделей нет фрамуг или дополнительной створки. В некоторых не может быть стеклопакета (например в противопожарной). Всё что не может быть, то прячется или дизаблится.
Заказчик сам настраивает что у конкретной модели может быть, а что нет.
А тебе не приходила в голову идея сделать для этого графический интерфейс? Чтобы заказчик редактировал нарисованную дверь и сразу видел как его изменения на неё повлияют.

fd00chмало того, что геморная реализация понадобится, так еще и невозможно делать групповые операции (выделить все, ничего, инвертировать или тупо выделить кучку строк, используя Shift/Ctrl и инвертировать чекбоксы, нажав на Space).Что там геморройного в реализации-то? Один старт потока, обложенного крит.секцией на каждое изменение статуса.
И в чём проблема с групповыми операциями-то? Всего-то послать запрос "insert select" для "выделить всё" да "delete без условия" для "ничего". Инвертирование, конечно, похитрее будет, чтобы сделать его одним запросом нужно "merge delete", которое появилось только в тройке. С Ctrl строки всё равно выделяются по одной, Shift сам по себе геморроен с использовании при выделении большего количества чем видно на экране, так что проблем не создаст если наладить user-friendly feedback (например, расставлять чек-боксы в списке только после успешной отправки запроса - получится забавная анимация и прогресс-бар в одном флаконе).
Если бы мне пришлось делать интерфейс стиля списков при латентной сети, я бы делал его именно так (в случае если просто часики на время выполнения операции не прокатят).

fd00chне всегда ж юзер выбирает ID в списке по одному и не всегда полученные по этим ID строки юзер внимательно просматривает по одной.
А как тогда он их выбирает и просматривает?

fd00chон задает критерии в фильтре
Так в чём проблема отослать на сервер один запрос с этими критериями?

fd00chчерез минуту/месяц, пока юзер думает/платит, некоторые записи будут неактуальны, какие-то - добавлены. повторно тот же результат не получить
В транзакции уровня concurency - легко!

fd00chи сколько мне ее держать открытой, если юзер не захочет этот кусок экспортировать, а запросит новый с другими критериями - пока сервер не перезагрузится?
Пока список, из которого пользователь выбирает, не обновится. Если список как раз и формируется по критериям, то аккорат до "запросит новый с другими критериями". По-моему так.