Цитата:
Сообщение от
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