Альтернатива 7-ми табличным датасоурсам

[samolalex]

Задачу решил использованием двух временных таблиц - для верхнего и для нижнего гридов:
1) В первую таблицу "накидал" поля из 4-таблиц, во вторую - из 3-х.
2) В ветке датасоурсов формы связал по типу Delayed.
3) Для каждой таблицы написал серверный статический метод для их заполнения путем выполения x++ запросов.
4) В методе init формы вызываю в соответствующем порядке каждый из вышеуказанных методов.
В итоге все работает стабильно и достаточно быстро (относительно заполнености таблиц).

Остался небольшой вопрос - является ли "адекватным" (регламентированным в среде MorphX) решением использование 2-х временных таблиц в качестве датасоурсов с точки зрения контекста поставленной мною задачи?

[sukhanchik]

Цитата:

Сообщение от samolalex

Остался небольшой вопрос - является ли "адекватным" (регламентированным в среде MorphX) решением использование 2-х временных таблиц в качестве датасоурсов с точки зрения контекста поставленной мною задачи?

Контекст поставленной Вами задачи таков - что кроме того, что Вам нужно брать данные из нескольких таблиц - больше ничего не известно.
Поэтому - можно предложить следующие варианты:
1. Выбрать какую-то одну таблицу в качестве основной и сделать несколько едит-методов для доступа данных к полям других таблиц.
"-" если едит-методов будет много (>5-6) - возможно ощущение тормозов. Хотя все зависит от размера таблиц, к которым обращается едит-метод - насколько запрос долгий. Также нет сортировки и фильтрации
"+" быстрая разработка, удобство в актуальности значений полей и отсутствия необходимости дополнительно обновлять данные.
2. Создать временные таблицы, в которых накидать те поля, которые нужны для отображения в форме.
"-" таблицы нужно заполнять при открытии формы и их содержимое нужно обратно "раскидывать" при закрытии формы. Если в таблицах будет содержаться > 30-40 записей - то просядет время открытия формы - т.к. если у постоянных таблиц в грид подгружается только видимое количество записей при открытии + 30 записей (т.е. порядка 40 записей) - то тут Вам нужно будет фактически записать в таблицы все записи, удовлетворяющие выборке из постоянной - чтобы сформировать нужный вариант. При этом, при закрытии формы возникает обратная задача - нужно снова обработать все записи, чтобы измененные данные внести в постоянные таблицы.
"+" следа от использования временных таблиц не останется
3. Джойн таблиц, от чего Вы хотите отказаться.
"-" большое количество таблиц (особенно если они объемные) сказывается на производительности
"+" в грид подгружаются не все записи - а только видимая часть + 30 записей. Также не нужно загружать/раскидывать данные как в случае временных таблиц.
4. п.2, только с использованием постоянных в БД таблиц.
"-" нужно прошерстить все изменения Вашего списка таблиц, чтобы в каждое изменение вставить копирование в Ваши таблицы. Либо предзаполнять создаваемые записи в форме. Помимо того, что это может быть просто неоправдано по логике - это естественно - не ускорит те процессы в которые Вы вклинитесь (например, если это разноска). А еще и увеличится время на разработку - т.к. нужно будет данные все равно подгружать и обратно раскидывать
"+" скорость и удобство работы (фильтрация и пр.).

Поэтому тут нужно смотреть по конкретной задаче.
Если вводится первичный документ - то это однозначно п.4 с предзаполнением полей при создании записи (например, создание заказа на продажу и заполнение ряда полей из справочника клиентов при выборе клиента).
Если данные нередактируемые - но нужно иметь их оперативно - то это п.4 со "вклиниванием" или п.3, если скорость приемлема. Аналог - расчет запасов в наличии - когда при изменении таблицы складских проводок (InventTrans) обновляется таблица запасов в наличии (InventSum)
Если это корректировка (без создания) какого-либо документа с каким-то индивидуальным интерфейсом для пользователя - то возможны п.1 или п.3. Даже возможен п.4 - например - разноска журнала коммерческих соглашений для установки цены.
Если таблица используется в мастере (Wizard) - то однозначно нужно иметь временные таблицы - чтобы в любой момент при нажатии пользователем кнопки отмены - состояние БД-бы не изменилось - это п.2

[BOAL]

Когда-то делали форму-запрос, где была куча джойнов (до 8) для получения нужного среза.
Кончилось тем, что переделали на временную таблицу, тк ее заполнение (даже с вложенными циклами) было быстрее, чем открытие такой формы (на пустых данных тормозило константное время на сам запрос).
Соотв, нужно протестить полученный вариант из многих джойнов на скорость инициации формы.

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

Можно еще едитметодами эмулировать поля из других таблиц.

А вообще 4 + 3 это не 7 подряд (и не 8 как у меня)
Это штатное применение
См форму Заказов тех же (уже не помню где конкретно, но точно видел) - там как раз 4 + 3 было
строки+ аналитики + линки + че-то там еще

Опять же сколько записей должно быть в подчиненной выборке, если 100000, то одно, если 10 - другое.

Карточки номенклатур штатные 5 таблиц на форме, если обвешаны древовидным справочником, то как раз 6-7 и будет. То есть, все от работоспособности итогового результата.

А так как проще сделать грид из связки, то так и нужно сделать - а потом уже оптимизировать, если придется вообще.

[samolalex]

sukhanchik, из вашего сообщения сделал вывод, что в контексте моей задачи использование временных таблиц скорее склоняется в сторону "Нет", чем "Да".

Поэтому переделал форму:
1) Создал 2 вьюшки, в первую поместил 4 таблицы, а во вторую - 3;
2) Эти представления использую в качестве датасоурсов.