Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
 Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
Добрый вечер.
Не смог ничего найти приемлемого для себя в справочниках и гугле, вот решил задать вопрос.
Допустим, в БД хранится документ с двумя табличными частями - в трех таблицах соответственно. Задача состоит в запросе списка документов с содержимым всех табличных частей.
В аналоги могу лишь привести 1С : если сделать подобный запрос с итогами, с помощью нескольких выборок на разных уровнях иерархии можно обойти как шапки документов, так и табличные части. Здесь главным критерием является то, что запрос на сервер оформляется один. Код выглядит как обход дерева.
Ничего похожего без извращений я не могу придумать по отношению к Firebird. Была бы одна табличная часть - можно было бы просто сделать левое соединение табличной части к шапке по ключу документа, таким образом каждая строка табличной части сопровождалась бы комплектом реквизитов из шапки документа. Конечно, объем передаваемых данных умножается, но это не так критично (если не говорить о сотне реквизитов в шапке и табличной части).
Передо мной стоит задача работы с документами, содержащими несколько табличных частей. Решать в лоб - в цикле по каждому документу отдельными запросами к каждой табличной части - дилетантизм. Слишком медленно, даже с учетом предварительной подготовки запросов и работы через параметры.
Возможно написать хранимую процедуру, в которой уже циклами обработать все данные согласно структуре, но как в таком случае возвращать данные на клиента? В ячейке ведь нельзя передать коллекцию, как в Oracle? Составлять протокол ключ-значение и передавать иерархию, развернутую в список? Выглядит извращением и болью при необходимости изменить потом что-либо в структуре документа.
Подскажите, пожалуйста, как возможно решить подобную задачу одним запросом. Наверняка должны быть типовые решения.
Буду благодарен за указание любого источника, спасибо.
27 мар 19, 19:27    [21845380]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
superspy2019,

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

Интересно, как такую задачу решают профессионалы
27 мар 19, 19:31    [21845385]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9631
superspy2019,

такие вещи решаются на уровне сервера приложения с помощью ORM
27 мар 19, 20:38    [21845443]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
KreatorXXI
Member

Откуда: Москва
Сообщений: 689
superspy2019,

Вы пример бы привели. А так не очень понятно. Может вьюху можно построить. У меня есть вьюха типа дерева. Правда с ограниченным количеством уровней.
28 мар 19, 09:59    [21845767]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
m7m
Member

Откуда: Украина, Мариуполь
Сообщений: 1335
KreatorXXI
superspy2019,

Вы пример бы привели. А так не очень понятно. Может вьюху можно построить. У меня есть вьюха типа дерева. Правда с ограниченным количеством уровней.

Я его понял вот так:
Дерево да чтобы в разных узлах была разная структура данных и все это одним запросом
28 мар 19, 10:11    [21845783]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2780
superspy2019, если базу еще только предстоит написать, исходи из того, что никаких табличных частей не существует, а каждая сущность представляет из себя объект некоторого класса с атрибутами некоторых типов. Соответственно, в табличном представлении объект, это строка, а каждый атрибут объекта - столбец.
28 мар 19, 10:43    [21845829]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
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 возможно как-то развернуть, чтобы стало понятнее, о чем идет речь?
28 мар 19, 10:53    [21845838]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
rdb_dev,

я исхожу из того, что предметная область не может быть описана прямоугольной матрицей значений, т.к. суть ее объектов - иерархия разнотипных кортежей
28 мар 19, 10:54    [21845840]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9631
superspy2019,

а ты уверен что читать пол базы это хорошо? Обычно если нужны детали заказа, то открывают конкретный заказ, и тогда уже делают 4 select, а не так выбрали все заказы с ДАТА НАЧАЛА по ДАТА ОКОНЧАНИЯ и выбрали сразу для всех все детальки
28 мар 19, 11:14    [21845869]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2780
superspy2019
rdb_dev,
я исхожу из того, что предметная область не может быть описана прямоугольной матрицей значений, т.к. суть ее объектов - иерархия разнотипных кортежей
Может! Просто спроецируй 3NF не на сущности данных, а на типы данных.
Пример:
* Таблица классов содержит идентификатор класса, индексируемый ASCII тэг, friendly-user имя и прочие атрибуты, идентификатор наследуемого класса;
* Таблица членов класса содержит внешний ключ на идентификатор класса, идентификатор члена класса, порядковый номер члена, индексируемый ASCII тэг, friendly-user имя, указатель на тип данных (INT4, INT8, FLOAT4, FLOAT8, VCHR, BLOB, TMSTMP) и указатель на соответствующую типу данных интерпретацию (IPv4 для INT4, CLASSID для INT8, BCDEL/BCDEB для INT4 или INT8 и т.д.) и т.д.;
* Таблица объектов содержит идентификатор объекта, идентификатор класса, friendly-user наименование и т.д.;
* Таблица определённого типа значений атрибутов объекта содержит идентификатор атрибута, идентификатор члена класса, значение заданного типа;

Расписывать полностью представление структуры ORM в "прямоугольной матрице" не стану, так как там дофига чего ещё.
28 мар 19, 11:49    [21845922]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
rdb_dev,

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

Чистой древовидной архитектуры здесь нет, все выглядит как один большой костыль, лишь бы хоть как-то решить задачу с помощью плоской таблицы.
28 мар 19, 11:58    [21845932]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
Симонов Денис,

обычно, если БД разработана для задачи предварительной обработки (сведения из разных источников, приведения к унифицированной структуре, пересчета или подбора значений) и выгрузки полученной выборки в основную учетную систему - единственное решение читать готовый к выгрузке объем данных и обрабатывать его согласно алгоритму синхронизации. Я же не говорю, что требуется вручную открывать каждый элемент, проверять его и нажимать на кнопку "Сохранить и отправить". Задачи обычно немножко более сложные и автоматизированные.
28 мар 19, 12:05    [21845941]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
m7m
Member

Откуда: Украина, Мариуполь
Сообщений: 1335
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 возможно как-то развернуть, чтобы стало понятнее, о чем идет речь?

ну так ты все и написал: 4-ре связанных датасета + нужные фильтры
И если очень хочется то строй дерево, однако я-бы просто показал все это в 4-х гридках и не парился.
ps. Беспокойство по поводу " read_committed транзакция уже не подойдет, придется либо собирать мусор на версиях, либо вовсе терпеть блокировки для чтения" не понял
28 мар 19, 12:08    [21845946]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9631
superspy2019,

вы уж решите что именно делаете. Если у вас логика в сервере приложений и вы хотите всё обрабатывать в виде объектных моделей, то вам нужен слой который преобразует запросы к объектной модели в SQL, а возвращаемый результат обратно в объектную модель. Это и есть ORM упрощённо. А потом со своими объектами делайте что хотите.

А просто обработать кучу данных, не таща их на клиента, то это можно и внутри ХП, безо всяких там вложенных объектных структур.
28 мар 19, 12:22    [21845966]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9631
superspy2019
В теории, если склеить кучу left join в одну таблицу и идти разными циклами по разным столбцам, а первый попавшийся NULL считать окончанием данных в "подтаблице" (назовем приклеенные столбцы из подчиненной таблицы так), то что-то похожее на правду возможно получить. Однако, это справедливо только для простейших случаев.


ну зачем же такую откровенную чепуху нести. Глянь на свои связанные таблицы внимательно. У всех них есть ORDER_ID который и является группирующим элементом. И NULL тут не причём. Сущности относящиеся к одному и тому же заказу будут иметь один и тот же ORDER_ID. Возьми для примера любую ORM и посмотри как оно там сделано. Все они построены на объектах и их коллекциях. И самое интересное, почти ни одна из них не использует объектные навороты СУБД вроде Oracle. Фигачут обычными SQL запросами к обычным реляционным СУБД.
28 мар 19, 12:31    [21845978]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
KreatorXXI
Member

Откуда: Москва
Сообщений: 689
Эти четыре селекта можно засунуть в union. Если уж хочется одним запросом. Ну и дальше развивать можно.
28 мар 19, 13:25    [21846049]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9631
KreatorXXI,

да не нужен там никакой union. Обычный select с left join, как результат распихивать по объектной модели отдельная тема.

ТС надо либо взять готовую ORM, либо написать самому что-то подобное. Но в последнем случае "программист нужен" ©
28 мар 19, 13:38    [21846068]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
KreatorXXI
Member

Откуда: Москва
Сообщений: 689
Симонов Денис,

я решил это "распихивание" сделать на сервере через вьюху с union'ом. На клиенте посчитал - не кошерно. Мои "старые проверенные" коллеги предпочитают работать на клиенте. Но с терминами типа ORM да и просто с головой проблемы, поэтому всё получается через многочисленные селекты. Бедный сервер.
28 мар 19, 14:29    [21846125]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47675

KreatorXXI
я решил это "распихивание" сделать на сервере через вьюху с union'ом. На клиенте посчитал
- не кошерно.

Да ты в натуре гой еси, добрый молодец.

Posted via ActualForum NNTP Server 1.5

28 мар 19, 14:39    [21846143]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
KreatorXXI,

Уважаемый, union работает только с потоками данных одинаковой структуры. Мой пост совершенно о другом
29 мар 19, 13:39    [21847010]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
Симонов Денис,

Не могу согласиться в том, что мои слова являются чепухой. Проецирование дерева в одну таблицу приблизительно тем методом, что я описал - левым соединением строк каждой табличной части с таблицей заголовков по ключу и объединением в одну выборку по столбцам, - отличается от метода "1 селект на каждую табличную часть" очень сильно. Не столько количеством запросов, сколько стратегией управления транзакциями. Мы же с вами говорим не про студенческую курсовую
29 мар 19, 13:43    [21847015]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47675

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

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

Posted via ActualForum NNTP Server 1.5

29 мар 19, 13:47    [21847024]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

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


Понять это можно, имея представление о различных уровнях изоляций и соответствующих стратегиях управления ими. Простите, я не знаю ваш уровень компетенции.
Если говорить образно - read_committed транзакция прочитает любую закоммиченную версию - не важно, какой транзакцией и в какой момент времени это произошло. Если разными селектами выбирать части одного объекта - теоретически возможна ситуация, когда пользователь параллельно с вами выполняет сохранение изменений в этом объекте, один ваш селект прочитал запись для старого объекта, второй селект прочитал запись уже нового объекта. В итоге вы получаете чепуху. Это же азы многопоточности.
Чтобы этого избежать, нужен либо более строгий уровень изоляции, либо стратегия блокировок. И уже при попытке прочитать объект получать либо всегда данные одной версии (не важно, что уже закоммичено обновление данных этого объекта) - здесь напарываемся на непрогнозируемые проседания производительности СУБД при сборке мусора, либо всегда получаем исключение при наличии более новой версии - суть есть блокировки, необходимость повторного запроса
29 мар 19, 13:48    [21847027]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47675

superspy2019
здесь напарываемся на непрогнозируемые проседания производительности СУБД при сборке
мусора, либо всегда получаем исключение при наличии более новой версии - суть есть
блокировки, необходимость повторного запроса

У-у-у, как всё запущенно...

Posted via ActualForum NNTP Server 1.5

29 мар 19, 13:54    [21847034]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

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


Вообще, основные вещи, которые мне приходится разрабатывать - десериализовать структуру, хранить ее в БД, сериализовать в другом формате. Сильно упрощенно и образно. Про UI я ничего не говорю. Мне нужен лишь оптимальный способ получения максимально подходящей к сериализации сразу после выборки структуры данных - как можно меньшим количеством запросов, как можно меньшим количеством клиентского кода для обработки, как можно более быстрым способом управления транзакциями.
К сожалению, все это сразу на пальцах объяснить не получается
29 мар 19, 13:55    [21847037]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
Все форумы / Firebird, InterBase Ответить