Добрый вечер.
Не смог ничего найти приемлемого для себя в справочниках и гугле, вот решил задать вопрос.
Допустим, в БД хранится документ с двумя табличными частями - в трех таблицах соответственно. Задача состоит в запросе списка документов с содержимым всех табличных частей.
В аналоги могу лишь привести 1С : если сделать подобный запрос с итогами, с помощью нескольких выборок на разных уровнях иерархии можно обойти как шапки документов, так и табличные части. Здесь главным критерием является то, что запрос на сервер оформляется один. Код выглядит как обход дерева.
Ничего похожего без извращений я не могу придумать по отношению к Firebird. Была бы одна табличная часть - можно было бы просто сделать левое соединение табличной части к шапке по ключу документа, таким образом каждая строка табличной части сопровождалась бы комплектом реквизитов из шапки документа. Конечно, объем передаваемых данных умножается, но это не так критично (если не говорить о сотне реквизитов в шапке и табличной части).
Передо мной стоит задача работы с документами, содержащими несколько табличных частей. Решать в лоб - в цикле по каждому документу отдельными запросами к каждой табличной части - дилетантизм. Слишком медленно, даже с учетом предварительной подготовки запросов и работы через параметры.
Возможно написать хранимую процедуру, в которой уже циклами обработать все данные согласно структуре, но как в таком случае возвращать данные на клиента? В ячейке ведь нельзя передать коллекцию, как в Oracle? Составлять протокол ключ-значение и передавать иерархию, развернутую в список? Выглядит извращением и болью при необходимости изменить потом что-либо в структуре документа.
Подскажите, пожалуйста, как возможно решить подобную задачу одним запросом. Наверняка должны быть типовые решения.
Буду благодарен за указание любого источника, спасибо.

superspy2019,

единственное разумное, что могу себе представить - для моего примера использовать три селекта с условием отбора документов (а-ля "Дата документа = ...") - к таблице с шапками и таблицам с табличными частями. На клиенте строить словарь шапок и по ключу городить деревянную структуру.

Интересно, как такую задачу решают профессионалы

m7m,

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

Пример можно привести, например, такой:
Таблица Заказ: ORDER_ID, ORDER_DATE, ORDER_NUMBER, DELIVERY_DATE, DELIVERY_PLACE
Таблица Товары: ORDER_ID, ITEM_ID, GTIN, DESCRIPTION, NETPRICE, TAXRATE
Таблица ЛогистическиеОкна: ORDER_ID, LOG_ID, DATETIME_FROM, DATETIME_TO, COMMENT
Таблица ДопИнфо: ORDER_ID, KEY, VALUE

Соответственно, чтобы запросить все заказы с датой доставки = DELIVERY_DATE, я бы сделал 4 селекта и строил дерево на клиенте. При этом, если документы (да не обязательно документы - справочники, регистры, что угодно в принципе с иерархической структурой) могут изменяться параллельно разными пользователями, read_committed транзакция уже не подойдет, придется либо собирать мусор на версиях, либо вовсе терпеть блокировки для чтения. Но это отдельная история.

При этом, если понадобится сделать фильтр а-ля "заказы с логистическим окном с 2:00 - 4:00, в которых присутствует номенклатура из группы весовых сыров", я в первую очередь растеряюсь и буду долго сидеть кипеть в попытке что-нибудь придумать.

Вариант с использованием ORM возможно как-то развернуть, чтобы стало понятнее, о чем идет речь?

rdb_dev,

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

rdb_dev,

нет, ну физически конечно можно все, что угодно мапировать в единую таблицу - набор колонок для шапки, колонки для товаров, колонки для окон и т.д. При этом надо учитывать пропорции между количеством строк в таблицах - если заказы имеют от 50 до 300 товаров, то лог.окна обычно приходят в количестве 1-2 строки в 1 из 2000 заказов.
В теории, если склеить кучу left join в одну таблицу и идти разными циклами по разным столбцам, а первый попавшийся NULL считать окончанием данных в "подтаблице" (назовем приклеенные столбцы из подчиненной таблицы так), то что-то похожее на правду возможно получить. Однако, это справедливо только для простейших случаев.
При формате "табличные части в элементах табличных частей" (на практике встретится проще простого) - кроме как декартово произведение ничего придумтаь невозможно. И конечный набор данных станет, во-первых, дико большим, даже, я бы сказал, заметным в трафике, во-вторых, непригодным для чистого обхода и требующим свой алгоритм обработки.

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

Симонов Денис,

обычно, если БД разработана для задачи предварительной обработки (сведения из разных источников, приведения к унифицированной структуре, пересчета или подбора значений) и выгрузки полученной выборки в основную учетную систему - единственное решение читать готовый к выгрузке объем данных и обрабатывать его согласно алгоритму синхронизации. Я же не говорю, что требуется вручную открывать каждый элемент, проверять его и нажимать на кнопку "Сохранить и отправить". Задачи обычно немножко более сложные и автоматизированные.

KreatorXXI,

Уважаемый, union работает только с потоками данных одинаковой структуры. Мой пост совершенно о другом

Симонов Денис,

Не могу согласиться в том, что мои слова являются чепухой. Проецирование дерева в одну таблицу приблизительно тем методом, что я описал - левым соединением строк каждой табличной части с таблицей заголовков по ключу и объединением в одну выборку по столбцам, - отличается от метода "1 селект на каждую табличную часть" очень сильно. Не столько количеством запросов, сколько стратегией управления транзакциями. Мы же с вами говорим не про студенческую курсовую

[quot m7m]superspy2019m7m,
Беспокойство по поводу " read_committed транзакция уже не подойдет, придется либо собирать мусор на версиях, либо вовсе терпеть блокировки для чтения" не понял

Понять это можно, имея представление о различных уровнях изоляций и соответствующих стратегиях управления ими. Простите, я не знаю ваш уровень компетенции.
Если говорить образно - read_committed транзакция прочитает любую закоммиченную версию - не важно, какой транзакцией и в какой момент времени это произошло. Если разными селектами выбирать части одного объекта - теоретически возможна ситуация, когда пользователь параллельно с вами выполняет сохранение изменений в этом объекте, один ваш селект прочитал запись для старого объекта, второй селект прочитал запись уже нового объекта. В итоге вы получаете чепуху. Это же азы многопоточности.
Чтобы этого избежать, нужен либо более строгий уровень изоляции, либо стратегия блокировок. И уже при попытке прочитать объект получать либо всегда данные одной версии (не важно, что уже закоммичено обновление данных этого объекта) - здесь напарываемся на непрогнозируемые проседания производительности СУБД при сборке мусора, либо всегда получаем исключение при наличии более новой версии - суть есть блокировки, необходимость повторного запроса

m7mИ если очень хочется то строй дерево, однако я-бы просто показал все это в 4-х гридках и не парился.


Вообще, основные вещи, которые мне приходится разрабатывать - десериализовать структуру, хранить ее в БД, сериализовать в другом формате. Сильно упрощенно и образно. Про UI я ничего не говорю. Мне нужен лишь оптимальный способ получения максимально подходящей к сериализации сразу после выборки структуры данных - как можно меньшим количеством запросов, как можно меньшим количеством клиентского кода для обработки, как можно более быстрым способом управления транзакциями.
К сожалению, все это сразу на пальцах объяснить не получается