Вход | Регистрация


1С:Предприятие :: 1С:Предприятие 8 общая

Оптимизация поиска в УФ с большим числом строк. Как в УФ хранить ТЗ только на сервере?

Оптимизация поиска в УФ с большим числом строк. Как в УФ хранить ТЗ только на сервере?
Я
   Rema Dan
 
30.03.18 - 13:11
Осваиваю УФ. На форме 2 табличных части ~100 и ~10000 строк. Нужно иметь возможность для произвольной строки из малой таблицы быстро найти соответствующие ей 30-50 строк из большой таблицы. Соответствия строк рассчитываются при создании формы и не меняются при работе в форме. Как не меняются и сами строки.
Вопрос в том как правильно было бы хранить соответствия строк между 2-ух таблиц? Хранить на клиенте не вариант, потому что гонять туда-сюда эти соответствия может быть весьма обременительно, форма и так тяжёлая на подъём. Да и отсутствие на клиенте коллекций с быстрым поиском не помогает.
Хотелось бы хранить все соответствия на сервере и получать с сервера номера соответствующих строк безконтекстным вызовом. Как правильно организовать хранение такой ТЗ на сервере? Единственное, что я пока придумал, это поместить ТЗ во временное хранилище. Есть ли ещё варианты?
 
 
   vde69
 
1 - 30.03.18 - 13:14
1. в УФ не стоит использовать ТЗ на большое кол-во элементов (это связано с памятью и контекстом передачи)
2. для сабжа следует использовать динамический список и накладывать отборы
   Cyberhawk
 
2 - 30.03.18 - 13:16
Заведи реквизит формы и помещай свои 30-50 строк туда. Большую ТЧ с формы убери.
   Kondarat
 
3 - 30.03.18 - 13:20
(0)>>>На форме 2 табличных части
Путь к данным Табличные части или Таблица значений?
Если Табличные части, то соответствие строк хранить в реквизите табличной части хоть в виде УникальногоИдентификатор, устанавливать при заполнении ТЧ, затем устанавливать отбор.
   Rema Dan
 
4 - 30.03.18 - 13:28
(1) Данные большой ТЧ получаются из стороннего ПО и базе они не хранятся. Вариант с заменой на динамический список не подходит.
(2) Так ведь 30-50 - это на каждую строчку малой таблицы. Таблица соответствий может быть иметь значительные размеры.
   DmitrO
 
5 - 30.03.18 - 13:28
Как заявлено в документации, с сервера на клиент при контекстных вызовах передаются только изменения в данных формы, а не все подряд. А у нас, как заявлено в (0) ничего не меняется.

Не очень понятно, конечно, зачем вообще нужна такая форма в которой ничего не меняется..
   Cyberhawk
 
6 - 30.03.18 - 13:33
(4) Я не понял, зачем ты мне это написал
   vde69
 
7 - 30.03.18 - 13:33
(4) так сделайте регистр и храните в нем...
   Rema Dan
 
8 - 30.03.18 - 13:36
(3) Сейчас обе табличных части - это табличные части обработки. Одна строчка большой таблице может соответствовать нескольким малой, поэтому вариант хранения соответствий внутри ТЧ не подходит.
(5) Про наличие такой оптимизации не знал. А как она поведёт себя, если в ТЧ меняется значение одной колонки у нескольких строк ТЧ? Отправятся только эти строки? или вся ТЧ?
В форме меняются значения 2-ух колонок малой ТЧ на основании действий пользователя. При закрытии формы эти данные пишутся в базу.
   Rema Dan
 
9 - 30.03.18 - 13:39
(6) К тому, что если хранить ТЗ соответствий в реквизитах формы, то она начнёт гулять между вызовами. Хотя с учётом оптимизации из (5) это может уже быть неактуальной проблемой.
   Kondarat
 
10 - 30.03.18 - 13:41
(8)>>>Одна строчка большой таблице может соответствовать нескольким малой, поэтому вариант хранения соответствий внутри ТЧ не подходит.

Почему?

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

Строка 2 БТЧ, УИД = 2 Строка 4 МТЧ, УИД = 2
                      Строка 5 МТЧ, УИД = 2
                      Строка 6 МТЧ, УИД = 2
 
 Рекламное место пустует
   vde69
 
11 - 30.03.18 - 13:43
(9) блин... УФ расчитаны на WEB браузер, а они все собраны с использованием виртуальной ява машины, и в сесии реально памяти мало. я реально наступал на эти грабли... банально сесия зависает и все...
   DmitrO
 
12 - 30.03.18 - 13:48
(8) я бы на вашем месте изначально вместо табличных частей использовал бы форму вот с такой структурой:
https://yadi.sk/i/q8Pc_xCg3TukDh

По сути это ТЗ, в имеющая в колонке БольшаяТаблица для каждой строки свой экземпляр ТЗ своей структуры.
   vde69
 
13 - 30.03.18 - 13:49
(12) тогда лучше сразу дерево ...
   FIXXXL
 
14 - 30.03.18 - 13:51
(8) сделай третью ТЧ именно соответствий
   DmitrO
 
15 - 30.03.18 - 13:51
(13)а это зависит от особенностей задачи отображения данных на форме, иногда дерево не нужно, и даже наоборот отвратительно в своей неуправляемости.
   Rema Dan
 
16 - 30.03.18 - 13:51
(10) Одной строчки МТЧ соответствует много строк БТЧ. Одна и та же строчка БТЧ может быть связана с несколькими строчками МТЧ. Одна из решаемы этой обработкой задач - это как раз доведение до пользователя ситуации с подобным перекрытием. (11) Заказчик хочет видеть все записи из внешней базы. Я и так уже убедил его перейти на режим когда в малой ТЧ немного строк (иногда всего пара десятков). Путей избавиться от большой ТЧ я не вижу. Вариант с дополнительным регистром сведений интересен, но доработка метаданных базы в данном случае нежелательна.
   los_hooliganos
 
17 - 30.03.18 - 13:52
(8) Какой размер меняющихся значений в малой ТЧ?
По идее составной ключ будет равен число = [РазмерЗначений1]+[РазмерЗначений2]
   los_hooliganos
 
18 - 30.03.18 - 13:53
(17) Число будет образовано как сложение строки.
Например 8 Контрагентов плюс 3 Валюты = Ключ с максимум 83
   vde69
 
19 - 30.03.18 - 13:54
>>>Заказчик хочет видеть все записи из внешней базы

да пофиг чего он хочет, тут вопрос в другом - выполнимо это или нет...
   los_hooliganos
 
20 - 30.03.18 - 13:55
(16) Да какая разница, главное проставить рассчитанный ключ в большой ТЧ
   los_hooliganos
 
21 - 30.03.18 - 13:59
Либо вообще вести динамически ключи в 2х колонках.
Число полученное как сложенная строка из 2х колонок будет использовать в "Расширение таблицы формы для таблицы значений (Form table extension for value table)" ОтборСтрок (RowFilter)
   Buster007
 
22 - 30.03.18 - 14:00
"Использовать всегда" сними и будет тебе счастье
   Rema Dan
 
23 - 30.03.18 - 14:05
(12) На мой взгляд подобная структура поможет разве что хранить в строках малой таблицы несколько идентификаторов из большой.
(14) Именно это я и хочу сделать. Но я не хочу хранить это на клиенте. И вопрос темы как раз в том как лучше хранить это только на сервере.
(22) Это может быть решением. Я правильно понял, что если у реквизита формы не стоит галка "Использовать всегда" и он не вынесен на форму, то к нему можно будет свободно обращаться со стороны сервера и при этом он не будет отправляться клиенту?
   Buster007
 
24 - 30.03.18 - 14:06
(23) да
   Kondarat
 
25 - 30.03.18 - 14:07
(16) И?
>>>Нужно иметь возможность для произвольной строки из малой таблицы быстро найти соответствующие ей 30-50 строк из большой таблицы.

Уж определись с задачей.
   Cyberhawk
 
26 - 30.03.18 - 14:21
(9) Я не советовал тебе ничего про какую-то "ТЗ соответствий"
   DmitrO
 
27 - 30.03.18 - 14:28
(23)удивительно. Почему только идентификаторов, храните там все функциональные данные большой таблицы. Как раз никакие идентификаторы будут не нужны.
Если отношения между строками малой и большой таблицы известны сразу при инициализации формы, надо сразу так данные разложить и все.
   DmitrO
 
28 - 30.03.18 - 14:38
А вот если цель в том, чтобы не передавать все данные большой таблицы на клиента, потому что вероятно не все данные будут просмотрены, и это не жить не быть надо учесть в оптимизации, то тогда надо по другому.

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

По такому принципу работает, например расшифровка в СКД.
   Kondarat
 
29 - 30.03.18 - 14:40
(28) Перечитай 16 пост
   DmitrO
 
30 - 30.03.18 - 14:43
(29)перечитал, в чем я не прав?
   Kondarat
 
31 - 30.03.18 - 14:44
(30) Там отношение между таблицами многие ко многим. И задача несколько расширилась: Одна из решаемы этой обработкой задач - это как раз доведение до пользователя ситуации с подобным перекрытием
   Rema Dan
 
32 - 30.03.18 - 14:52
(28) Этот вариант разом решает и вопрос с отображением большой ТЧ на форме и вопрос с хранением ТЗ соответствий (её просто нет). Но разве при таком подходе не будет тратиться время время на сериализацию большой таблицы при доставании её из временного хранища? Можно ли этого как-нибудь избежать, храня в памяти сервера ТЗ без сериализаций туда-сюда?
К сожалению заказчик всё равно хочет видеть всю таблицу и придётся делать через ТЗ соответствий во временном хранилище или как предложено в (22)
(31) Вариант из (28) подходит поскольку в нём без проблем можно хранить несколько одинаковый записей большой таблицы с разными ключами малой.
(26) Теперь я понял, что в (2) был предложен вариант аналогичный (28)
   DmitrO
 
33 - 30.03.18 - 14:56
Ну значит и перекрытие можно описывать в реквизитах большой сразу при инициализации формы, строки можно (и даже наверно проще) дублировать в первой архитектуре данных формы, в данных большой сразу будет информация о перекрытии, удобно для отображения.

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

в любом случае можно делать построение формы и так и так.
 
 
   DmitrO
 
34 - 30.03.18 - 15:01
Во временном хранилище сериализация случится только в случае перехода сеанса с одного рабочего процесса на другой. При нормальной работе при получении данных из временного хранилища ты получаешь тот же самый объект который ты туда опускал (физически тот же самый, это как кеш по идентификатору!).
   DmitrO
 
35 - 30.03.18 - 15:13
(34)+
Точнее десериализация. Сериализация-то происходит при помещении.
   Rema Dan
 
36 - 30.03.18 - 15:17
(34) Замечательно. Тогда вариант с хранением ТЗ соответствий во временном хранилище и доставанием из него ключей нужных строк внеконтекстным вызовом кажется мне самым подходящим. В отличие от варината (22) в хранимой ТЗ можно будет сразу проиндексировать данные по нужным полям для ускорения поиска.
   DmitrO
 
37 - 30.03.18 - 15:21
Да, только как ты засунешь в форму отобранные строки в безконтекстном вызове. :)
Вызов будет контекстный, да это не беда.


Список тем форума
Рекламное место пустует  Рекламное место пустует
Прочитай, хотя бы, Митичкина "Разработка в системе 1С:Предприятие 8". Волшебник
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует