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

[samolalex]

Доброго времени суток!

Хотелось бы узнать ваше мнение относительно моей задачи.
Существует форма с двумя гридами (верхний и нижний). В верхнем гриде должны отображаться поля из 4-х таблиц, в нижнем - из 3-х. Некоторые из полей должны иметь возможность редактирования. Однозначно не могу решить, что лучше использовать с точки зрения быстродействия - представление, временную таблицу или оставить совокупность связанных табличных источников данных.
Какими стандартными средствами среды MorphX можно заменить эти 7 табличных датасоурсов, связанных между собой?

[sukhanchik]

Есть еще вариант (если конечно идеологически подходит). Одна постоянная таблица и кнопка "Разноска" (или ее аналог). По нажатию кнопки данные "раскидываются" по всем нужным таблицам.
Кстати - это самый что ни на есть штатный подход. Что такое разноска в ГК? Как раз формирование записей в нескольких таблицах.
Еще пример - разноска журнала коммерческих соглашений. "Имитирование" разноски для возможности запрета правки основной таблицы.

[kornix]

Цитата:

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

Доброго времени суток!

Хотелось бы узнать ваше мнение относительно моей задачи.
Существует форма с двумя гридами (верхний и нижний). В верхнем гриде должны отображаться поля из 4-х таблиц, в нижнем - из 3-х. Некоторые из полей должны иметь возможность редактирования. Однозначно не могу решить, что лучше использовать с точки зрения быстродействия - представление, временную таблицу или оставить совокупность связанных табличных источников данных.
Какими стандартными средствами среды MorphX можно заменить эти 7 табличных датасоурсов, связанных между собой?

Ну если наблюдается ситуация использования датасорса для отображения одного-двух полей - написать на датасорсах edit методы, тогда вместо 4-х датасорсов будет 2? Или даже 1?

[samolalex]

Цитата:

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

Ну если наблюдается ситуация использования датасорса для отображения одного-двух полей - написать на датасорсах edit методы, тогда вместо 4-х датасорсов будет 2? Или даже 1?

А можно ли создавать edit-методы на датасоурсах, вроде как, они создаются только на таблицах в отличие от дисплейных методов? Дело в том, что не хотелось бы создавать новые методы на существующих таблицах.

[kornix]

Цитата:

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

А можно ли создавать edit-методы на датасоурсах, вроде как, они создаются только на таблицах в отличие от дисплейных методов? Дело в том, что не хотелось бы создавать новые методы на существующих таблицах.

конечно можно, программный код, написанный на датасорсе выполняется на сервере (если я ничего не путаю, это даже BestPractice). Если датасорса 4 ради 5-ти полей - легче использовать edit методы. Однако надо помнить, что по edit-полю у вас не будет работать фильтр и поиск

[kornix]

...сейчас нет аксапты под рукой, но например на форме фактур подставляется картинка (источник фактуры), эта картинка - пример работы display метода (он вроде на datasource FactureJour_RU написан в тройке), чрезвычайно удобно!

[sukhanchik]

Цитата:

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

А можно ли создавать edit-методы на датасоурсах,

Их можно делать как на датасорсах, так и на самой контрольке и даже на форме в целом.

Цитата:

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

Однако надо помнить, что по edit-полю у вас не будет работать фильтр и поиск

А также при сложных вычислениях или большом обилии дисплей/едит методов - тормоза ...

[tricky]

Цитата:

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

конечно можно, программный код, написанный на датасорсе выполняется на сервере (если я ничего не путаю, это даже BestPractice). Если датасорса 4 ради 5-ти полей - легче использовать edit методы. Однако надо помнить, что по edit-полю у вас не будет работать фильтр и поиск

Если я чего-то не путаю, то все методы формы выполняются на клиенте.

[kornix]

Цитата:

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

А также при сложных вычислениях или большом обилии дисплей/едит методов - тормоза ...

Даа... бывают формы, ну совсем уж перегруженные дисплейными/едит методами, например та же форма фактур. Лучше избегать использования в этих методах конструкций вроде while select по большой таблице. Хотя есть положительная сторона вопроса - display/edit отрабатывают только для видимой части выбранных данных. Т.е. только для тех строк в grid, которые видит пользователь

[tricky]

Цитата:

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

Доброго времени суток!

Хотелось бы узнать ваше мнение относительно моей задачи.
Существует форма с двумя гридами (верхний и нижний). В верхнем гриде должны отображаться поля из 4-х таблиц, в нижнем - из 3-х. Некоторые из полей должны иметь возможность редактирования. Однозначно не могу решить, что лучше использовать с точки зрения быстродействия - представление, временную таблицу или оставить совокупность связанных табличных источников данных.
Какими стандартными средствами среды MorphX можно заменить эти 7 табличных датасоурсов, связанных между собой?

Думаю, замарачиваться со временными таблицами не имеет смысла. 7 датасоурсов - это еще не катастрофа. Например на форме PurchTable их 8. При грамотном проектировании структуры и связей таблиц ничего страшного не должно происходить. На крайний случай, можно будет сделать вызов "строк" по отдельной кнопке, а не отображать их внизу формы. Как, например, это сделано в формах складских журналов.

[kornix]

Цитата:

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

Если я чего-то не путаю, то все методы формы выполняются на клиенте.

И даже те, кот. написаны на датасорсе? (я тоже могу ошибаться, но из первого экзамена Introduction development, который сдавал года 3 назад вроде отложилось так)

[tricky]

Цитата:

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

И даже те, кот. написаны на датасорсе? (я тоже могу ошибаться, но из первого экзамена Introduction development, который сдавал года 3 назад вроде отложилось так)

А что вам мешает проверить при помощи, например, этого:

    info(enum2str(xGlobal::clientKind()));

?
UPD: Поглядел, что у вас нет Аксапты под рукой.

[kornix]

Цитата:

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

А что вам мешает проверить при помощи, например, этого:

    info(enum2str(xGlobal::clientKind()));

?
UPD: Поглядел, что у вас нет Аксапты под рукой.

Tricky прав, на клиенте! Проверил на форме salesTable, добавил в дисплейный метод этот код - "client"
Спасибо, буду знать.

[samolalex]

Несмотря на то, что редактирование полей оказалось ненужным, необходимо наличие фильтров практически по всем полям на gride, поэтому использовать edit и display методы не получится.

Решил использовать временную таблицу с необходимыми полями в качестве датасоурса, в init формы буду ее заполнять результатом сложного запроса. Мне кажется, что применение View не является столь гибким инструментом для отображения результатов сложного запроса по 4-м таблицам (для верхнего грида) в отличие от временной таблицы.

[tricky]

Цитата:

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

Несмотря на то, что редактирование полей оказалось ненужным, необходимо наличие фильтров практически по всем полям на gride, поэтому использовать edit и display методы не получится.

Решил использовать временную таблицу с необходимыми полями в качестве датасоурса, в init формы буду ее заполнять результатом сложного запроса. Мне кажется, что применение View не является столь гибким инструментом для отображения результатов сложного запроса по 4-м таблицам (для верхнего грида) в отличие от временной таблицы.

Лучше откажитесь от этой идеи, пока не поздно .

На сколько я понял, к этой временной таблице вы будете джойнить "нормальные" таблицы (данные из другого грида)? В этом случае, вероятнее всего вы получите table scan по этим таблицам (источник: Оптимизация запроса - ranges).

Да и измененные пользователем данные придется записывать в БД - а это только усложняет алгоритм работы формы.

[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) Эти представления использую в качестве датасоурсов.

[sukhanchik]

Цитата:

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

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

Все определяется объемом данных. Я попытался расписать когда какая идея применяется - а там уж Вам надо самим оценивать. На тестовых данных можно и не понять кто в выигрыше. В рамках же академического примера - когда джойн постоянных таблиц заведомо выиграет перед временными - это джойн LedgerTrans на саму себя с целью получения запроса с дебетом слева и кредитом справа.
А сборка данных из разных таблиц в одну пару временных таблиц для печати ТОРГ-12 - гораздо шустрее джойнов - т.к. временные таблицы заполняются небольшим количеством данных.