Осваиваю УФ. На форме 2 табличных части ~100 и ~10000 строк. Нужно иметь возможность для произвольной строки из малой таблицы быстро найти соответствующие ей 30-50 строк из большой таблицы. Соответствия строк рассчитываются при создании формы и не меняются при работе в форме. Как не меняются и сами строки.
Вопрос в том как правильно было бы хранить соответствия строк между 2-ух таблиц? Хранить на клиенте не вариант, потому что гонять туда-сюда эти соответствия может быть весьма обременительно, форма и так тяжёлая на подъём. Да и отсутствие на клиенте коллекций с быстрым поиском не помогает.
Хотелось бы хранить все соответствия на сервере и получать с сервера номера соответствующих строк безконтекстным вызовом. Как правильно организовать хранение такой ТЗ на сервере? Единственное, что я пока придумал, это поместить ТЗ во временное хранилище. Есть ли ещё варианты?

1. в УФ не стоит использовать ТЗ на большое кол-во элементов (это связано с памятью и контекстом передачи)
2. для сабжа следует использовать динамический список и накладывать отборы

Заведи реквизит формы и помещай свои 30-50 строк туда. Большую ТЧ с формы убери.

(0)>>>На форме 2 табличных части
Путь к данным Табличные части или Таблица значений?
Если Табличные части, то соответствие строк хранить в реквизите табличной части хоть в виде УникальногоИдентификатор, устанавливать при заполнении ТЧ, затем устанавливать отбор.

(1) Данные большой ТЧ получаются из стороннего ПО и базе они не хранятся. Вариант с заменой на динамический список не подходит.
(2) Так ведь 30-50 - это на каждую строчку малой таблицы. Таблица соответствий может быть иметь значительные размеры.

Как заявлено в документации, с сервера на клиент при контекстных вызовах передаются только изменения в данных формы, а не все подряд. А у нас, как заявлено в (0) ничего не меняется.

Не очень понятно, конечно, зачем вообще нужна такая форма в которой ничего не меняется..

(4) Я не понял, зачем ты мне это написал

(4) так сделайте регистр и храните в нем...

(3) Сейчас обе табличных части - это табличные части обработки. Одна строчка большой таблице может соответствовать нескольким малой, поэтому вариант хранения соответствий внутри ТЧ не подходит.
(5) Про наличие такой оптимизации не знал. А как она поведёт себя, если в ТЧ меняется значение одной колонки у нескольких строк ТЧ? Отправятся только эти строки? или вся ТЧ?
В форме меняются значения 2-ух колонок малой ТЧ на основании действий пользователя. При закрытии формы эти данные пишутся в базу.

(6) К тому, что если хранить ТЗ соответствий в реквизитах формы, то она начнёт гулять между вызовами. Хотя с учётом оптимизации из (5) это может уже быть неактуальной проблемой.

(8)>>>Одна строчка большой таблице может соответствовать нескольким малой, поэтому вариант хранения соответствий внутри ТЧ не подходит.

Почему?

Строка 1 БТЧ, УИД = 1 Строка 1 МТЧ, УИД = 1
                      Строка 2 МТЧ, УИД = 1
                      Строка 3 МТЧ, УИД = 1

Строка 2 БТЧ, УИД = 2 Строка 4 МТЧ, УИД = 2
                      Строка 5 МТЧ, УИД = 2
                      Строка 6 МТЧ, УИД = 2

(9) блин... УФ расчитаны на WEB браузер, а они все собраны с использованием виртуальной ява машины, и в сесии реально памяти мало. я реально наступал на эти грабли... банально сесия зависает и все...

(8) я бы на вашем месте изначально вместо табличных частей использовал бы форму вот с такой структурой:
https://yadi.sk/i/q8Pc_xCg3TukDh

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

(12) тогда лучше сразу дерево ...

(8) сделай третью ТЧ именно соответствий

(13)а это зависит от особенностей задачи отображения данных на форме, иногда дерево не нужно, и даже наоборот отвратительно в своей неуправляемости.

(10) Одной строчки МТЧ соответствует много строк БТЧ. Одна и та же строчка БТЧ может быть связана с несколькими строчками МТЧ. Одна из решаемы этой обработкой задач - это как раз доведение до пользователя ситуации с подобным перекрытием. (11) Заказчик хочет видеть все записи из внешней базы. Я и так уже убедил его перейти на режим когда в малой ТЧ немного строк (иногда всего пара десятков). Путей избавиться от большой ТЧ я не вижу. Вариант с дополнительным регистром сведений интересен, но доработка метаданных базы в данном случае нежелательна.

(8) Какой размер меняющихся значений в малой ТЧ?
По идее составной ключ будет равен число = [РазмерЗначений1]+[РазмерЗначений2]

(17) Число будет образовано как сложение строки.
Например 8 Контрагентов плюс 3 Валюты = Ключ с максимум 83

>>>Заказчик хочет видеть все записи из внешней базы

да пофиг чего он хочет, тут вопрос в другом - выполнимо это или нет...

(16) Да какая разница, главное проставить рассчитанный ключ в большой ТЧ

Либо вообще вести динамически ключи в 2х колонках.
Число полученное как сложенная строка из 2х колонок будет использовать в "Расширение таблицы формы для таблицы значений (Form table extension for value table)" ОтборСтрок (RowFilter)

"Использовать всегда" сними и будет тебе счастье

(12) На мой взгляд подобная структура поможет разве что хранить в строках малой таблицы несколько идентификаторов из большой.
(14) Именно это я и хочу сделать. Но я не хочу хранить это на клиенте. И вопрос темы как раз в том как лучше хранить это только на сервере.
(22) Это может быть решением. Я правильно понял, что если у реквизита формы не стоит галка "Использовать всегда" и он не вынесен на форму, то к нему можно будет свободно обращаться со стороны сервера и при этом он не будет отправляться клиенту?

(23) да

(16) И?
>>>Нужно иметь возможность для произвольной строки из малой таблицы быстро найти соответствующие ей 30-50 строк из большой таблицы.

Уж определись с задачей.

(9) Я не советовал тебе ничего про какую-то "ТЗ соответствий"

(23)удивительно. Почему только идентификаторов, храните там все функциональные данные большой таблицы. Как раз никакие идентификаторы будут не нужны.
Если отношения между строками малой и большой таблицы известны сразу при инициализации формы, надо сразу так данные разложить и все.

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

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

По такому принципу работает, например расшифровка в СКД.

(28) Перечитай 16 пост

(29)перечитал, в чем я не прав?

(30) Там отношение между таблицами многие ко многим. И задача несколько расширилась: Одна из решаемы этой обработкой задач - это как раз доведение до пользователя ситуации с подобным перекрытием

(28) Этот вариант разом решает и вопрос с отображением большой ТЧ на форме и вопрос с хранением ТЗ соответствий (её просто нет). Но разве при таком подходе не будет тратиться время время на сериализацию большой таблицы при доставании её из временного хранища? Можно ли этого как-нибудь избежать, храня в памяти сервера ТЗ без сериализаций туда-сюда?
К сожалению заказчик всё равно хочет видеть всю таблицу и придётся делать через ТЗ соответствий во временном хранилище или как предложено в (22)
(31) Вариант из (28) подходит поскольку в нём без проблем можно хранить несколько одинаковый записей большой таблицы с разными ключами малой.
(26) Теперь я понял, что в (2) был предложен вариант аналогичный (28)

Ну значит и перекрытие можно описывать в реквизитах большой сразу при инициализации формы, строки можно (и даже наверно проще) дублировать в первой архитектуре данных формы, в данных большой сразу будет информация о перекрытии, удобно для отображения.

Во втором варианте под понятием ключ, а не имел в виду конкретное значение, это может быть набор из нескольки значений, по которуму отбираются строки большой (ни говорим о том что ключ уникален). Это просто некая сущность отбирающая строки большой по данным строки малой.

в любом случае можно делать построение формы и так и так.

Во временном хранилище сериализация случится только в случае перехода сеанса с одного рабочего процесса на другой. При нормальной работе при получении данных из временного хранилища ты получаешь тот же самый объект который ты туда опускал (физически тот же самый, это как кеш по идентификатору!).

(34)+
Точнее десериализация. Сериализация-то происходит при помещении.

(34) Замечательно. Тогда вариант с хранением ТЗ соответствий во временном хранилище и доставанием из него ключей нужных строк внеконтекстным вызовом кажется мне самым подходящим. В отличие от варината (22) в хранимой ТЗ можно будет сразу проиндексировать данные по нужным полям для ускорения поиска.

Да, только как ты засунешь в форму отобранные строки в безконтекстном вызове. :)
Вызов будет контекстный, да это не беда.