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

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

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

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

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

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

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

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

Откуда: с болот
Сообщений: 3059
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

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

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

Откуда: с болот
Сообщений: 3059
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

Откуда: Украина, Мариуполь
Сообщений: 1347
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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Dimitry Sibiryakov
Member

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

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

У тебя всё получится если ты выкинешь требование "как можно меньшим количеством запросов",
ибо от правильно составленных запросов серверу не плохеет. А если откажешься ещё и от "как
можно меньшим количеством клиентского кода" (поскольку кожа на пальцах нарастает быстрее,
чем стирается), то и вообще будет тебе счастье.

Posted via ActualForum NNTP Server 1.5

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

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

Dimitry Sibiryakov
если ты выкинешь требование "как можно меньшим количеством запросов",
ибо от правильно составленных запросов серверу не плохеет.

В этом случае, кстати, количество клиентского кода тоже сокращается: ты тупо пишешь
вложенные циклы и сериализуешь результаты простых запросов.

Posted via ActualForum NNTP Server 1.5

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

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


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

Ну таки да про UI это я сам додумал
По поводу решения проблемы я полностью согласен с Dimitry Sibiryakov
а уж прислушиваться к его советам или нет это решать тебе
29 мар 19, 15:51    [21847267]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
Dimitry Sibiryakov
если ты выкинешь требование "как можно меньшим количеством запросов",
ибо от правильно составленных запросов серверу не плохеет.


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

Основной критерий - это 1 запрос. Все остальное - объем кода и удобство разработки, - вторичны.
29 мар 19, 17:10    [21847389]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Dimitry Sibiryakov
Member

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

superspy2019
Основной критерий - это 1 запрос.

"Заберите товарища его брак и выдайте другой." (с)

Дай протелепаю: с текущей системе "куча запросов" - не препарированные и ты надеешься что
один непрепарированный запрос будет быстрее кучи препарирваонных?

Posted via ActualForum NNTP Server 1.5

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

Откуда: Украина, Мариуполь
Сообщений: 1347
superspy2019
Основной критерий - это 1 запрос. Все остальное - объем кода и удобство разработки, - вторичны.

Вот это "Основной критерий - это 1 запрос" и настораживает

зы. У меня создается впечатление что основной критерий-время обработки
но все узкие места "разобраны и вылизаны"
осталось разобраться только с количеством запросов.
29 мар 19, 17:37    [21847424]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

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

В целом, практически вся работа с СУБД происходит через сеть - вполне возможно, что кроссдоменно с удаленных площадок. Среднее время на запрос - 5-500 мс. Как советует архитектор выше - делать запросы в цикле, - уже накодили и теперь приходится все просто переписывать. Благо я гибче и инструментов у меня больше. И если задачу синхронизации с БД десятками тысяч insert / update / update or insert я эффективно решаю объединением в execute block скрипты (уменьшая количество запросов в сотник раз), то вот запрос структуры из разных таблиц сделан, на мой взгляд, не очень оптимально. В этом и хотелось бы разобраться глубже.
29 мар 19, 17:43    [21847439]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
ёёёёё
Member

Откуда:
Сообщений: 1004
superspy2019
...
Допустим, в БД хранится документ с двумя табличными частями - в трех таблицах соответственно. Задача состоит в запросе списка документов с содержимым всех табличных частей.
...

Всего лишь три запроса, не? А на клиенте разбирать, кому что относится.
29 мар 19, 19:49    [21847558]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

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

Уважаемый, прочитайте ветку от начала до конца, чтобы не повторять уже разобранные мной вопросы
29 мар 19, 20:03    [21847566]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
ёёёёё
Member

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

и что там у тебя "разобрано"? Сам себе придумал проблем из воздуха и лаешь на всех.
29 мар 19, 20:05    [21847567]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Dimitry Sibiryakov
Member

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

superspy2019
Благо я гибче и инструментов у меня больше.

Насколько больше? Параметризованные запросы входят в это число?

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

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

Posted via ActualForum NNTP Server 1.5

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

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

superspy2019
Среднее время на запрос - 5-500 мс.

А теперь, внимание, вопрос: какая часть этого времени тратится на prepare (отдельно),
execute (отдельно) и fetch (отдельно).

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 31
Dimitry Sibiryakov
А теперь, внимание, вопрос: какая часть этого времени тратится на prepare (отдельно),
execute (отдельно) и fetch (отдельно).


Вы уже продемонстрировали свой уровень, что еще хотите?
99% этого времени клиент в принципе не тратит, так как весь код асинхронный, однако в разрезе на запрос время уходит на ожидание TCP запроса. Я проводил замеры на небольших update, получил разницу между подготовленными с параметрами и текстовыми со случайными значениями запросами на грани статистической погрешности. Все одиночные запросы я параметризую - не из-за безопасности (нет у меня задач вытаскивать работу с SQL наружу, все запросы программируются), а просто потому что удобнее. Вы промахиваетесь с этой темой.
29 мар 19, 20:31    [21847581]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
m7m
Дерево да чтобы в разных узлах была разная структура данных и все это одним запросом


В общем, максимум из темы смог выжать запрос
select ITEMS.ORDER_ID ITEM_ORDER, ITEMS."POSITION" ITEM_POS, WINDOWS.ORDER_ID WIN_ORDER, WINDOWS."POSITION" WIN_POS
from ORDER_ITEMS ITEMS
full join ORDER_WINDOWS WINDOWS on WINDOWS.ORDER_ID = ITEMS.ORDER_ID and
      WINDOWS."POSITION" = ITEMS."POSITION"
order by 1 nulls last, 3 nulls last, 2 nulls last, 4 nulls last  


Пришлось вводить в каждую табличную часть поле POSITION, в котором строки нумеруются от 1 до N для каждого родителя.

Результат

ITEM_ORDERITEM_POSWIN_ORDERWIN_POS
1111
12NULLNULL
13NULLNULL
NULLNULL21
NULLNULL22

обходится двумя параллельными вложенными циклами, по одному на табличную часть - в моем случае ITEMS и WINDOWS. Значение NULL игнорируется. Соответственно, объект на клиенте заполняется в один проход по выборке, запрос один, данных относительно немного, алгоритм прост. В этом примере используется две колонки с ключом, т.к. задачу усложнил и принял возможность пустой табличной части. Можно избавиться от лишних колонок, введя внешний запрос с еще одним join'ом, но надо учитывать производительность.

Ничего более умного не могу придумать
29 мар 19, 20:50    [21847589]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Dimitry Sibiryakov
Member

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

superspy2019
Вы уже продемонстрировали свой уровень, что еще хотите?

Чтобы Вы таки продемонстрировали свой. Можете ли Вы точно предугадать сколько
round-trip-ов понадобится для выполнения запроса, или отдаётесь на волю компонент доступа,
которые имеют привычку делать ненужные вызовы? Это очень немаловажная деталь при работе
через сеть с высоким временем пинга.

Раз у вас там упоминалась какая-то репликация, не думали ли Вы поставить локальные зеркала
базы в удалённых филиалах?

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 31
Dimitry Sibiryakov
Чтобы Вы таки продемонстрировали свой.


Не знаю, с чего вы взяли, что я пришел сюда что-то показывать. Я пришел за умным советом. А вы, батенька, даете ужасные советы и пытаетесь троллить, выводя меня на эмоции.
29 мар 19, 22:53    [21847629]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 238
superspy2019
Не знаю, с чего вы взяли, что я пришел сюда что-то показывать. Я пришел за умным советом. А вы, батенька, даете ужасные советы и пытаетесь троллить, выводя меня на эмоции.

ну ты нашел место, куда прийти за умным советом. лет 10 наблюдаю за веткой фб, в лучшем случае эти добрые люди советуют убиться о стену

в запрос вникать лень, но на счет тразакции учти, фб не оракл. read committed там не гарантирует консистентного набора. 1 или 4 запроса вернут кашу с одинаковой вероятностью. судя по всему тебе нужна snapshot транзакция и 4 запроса в рамках снепшот транзакции
30 мар 19, 00:06    [21847649]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
m7m
Member

Откуда: Украина, Мариуполь
Сообщений: 1347
superspy2019
В общем, максимум из темы смог выжать запрос
select ITEMS.ORDER_ID ITEM_ORDER, ITEMS."POSITION" ITEM_POS, WINDOWS.ORDER_ID WIN_ORDER, WINDOWS."POSITION" WIN_POS
from ORDER_ITEMS ITEMS
full join ORDER_WINDOWS WINDOWS on WINDOWS.ORDER_ID = ITEMS.ORDER_ID and
      WINDOWS."POSITION" = ITEMS."POSITION"
order by 1 nulls last, 3 nulls last, 2 nulls last, 4 nulls last  



Пришлось вводить в каждую табличную часть поле POSITION, в котором строки нумеруются от 1 до N для каждого родителя.

И теперь если удалится строка из табличной части надо будет заново проводить нумерацию или как?
30 мар 19, 00:51    [21847654]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

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

Абсолютно верно - выше я этот вопрос озвучил. Либо snapshot с блокированием на запись, либо собирать мусор на версиях. Сложно на самом деле, поэтому вариант нескольких параллельных селектов мне не нравится
30 мар 19, 14:22    [21847797]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
m7m
И теперь если удалится строка из табличной части надо будет заново проводить нумерацию или как?


Да, выходит так. При наличии потребности изменять хранящиеся объекты - придется при таком подходе городить хранимые процедуры для пересчета каждой такой таблицы.
Вообще, я уже ближе подошел к решению в виде разворачивания структуры в таблицу (на примере выше), но до конца пока не получается сделать, как мне бы хотелось. Либо получаю нужные мне NULL и на сдачу лишние столбцы, либо столбец родителя один, но связанные строки дублируются. Как смогу собрать задачу - напишу просьбу помочь составить запрос. Сейчас не смогу точный ТЗ описать.
30 мар 19, 14:27    [21847800]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Dimitry Sibiryakov
Member

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

superspy2019
Либо snapshot с блокированием на запись, либо собирать мусор на версиях.

У тебя чисто читающая транзакция. О каких блокировках и мусоре ты говоришь?

Posted via ActualForum NNTP Server 1.5

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

Откуда: Украина, Мариуполь
Сообщений: 1347
superspy2019
m7m
И теперь если удалится строка из табличной части надо будет заново проводить нумерацию или как?


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

Хранимая процедура с использованием явных курсоров позволит отказаться от доп.поля POSITION
superspy2019
Вообще, я уже ближе подошел к решению в виде разворачивания структуры в таблицу (на примере выше), но до конца пока не получается сделать, как мне бы хотелось. Либо получаю нужные мне NULL и на сдачу лишние столбцы, либо столбец родителя один, но связанные строки дублируются. Как смогу собрать задачу - напишу просьбу помочь составить запрос. Сейчас не смогу точный ТЗ описать.

и чует душа моя что результат будет один "широкий" набор со всеми полями из всех таблиц. Не мне судить насколько этот один запрос "лучше" четырех
30 мар 19, 14:56    [21847818]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
Dimitry Sibiryakov
У тебя чисто читающая транзакция. О каких блокировках и мусоре ты говоришь?


Да, я выразился совершенно неправильно, перепутав местами условия. Snapshot транзакция использует версионность и не дает возможность прочитать обновленные после ее старта данные. Именно использование snapshot на чтение вынуждает СУБД хранить версии записей и потом их чистить. Read_committed readonly транзакция не вынуждает собирать версии, но потребует заблокировать нужные записи, иначе нельзя гарантировать консистентность, о чем абсолютно точно сказал H5N1. Причем Firebird (знаю только про 2.5) по умолчанию вопреки канонам использует вариант no_record_version, что приводит к двухфазной блокировке и дает исключение при попытке прочитать неконсистентный набор.

Про все это я уже говорил выше, здесь вынужден повторяться
30 мар 19, 15:00    [21847820]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
m7m
Хранимая процедура с использованием явных курсоров позволит отказаться от доп.поля POSITION


Я, к сожалению, не умею работать с курсорами и не владею матчастью, никак не могу это прокомментировать.

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


Вообще, это классический подход выборки структурированных данных, из уст моего коллеги. Но он вошел в тупик, когда я спросил - что делать, если у одного родителя несколько различных по структуре узлов и каждый узел может быть родителем для других узлов - такой подход не подойдет. И ничего лучше сам придумать пока не могу.
Для нескольких запросов придется задуматься либо над настройкой транзакции, либо получить теоретическую вероятность внезапных проблем с производительностью, БД не маленькая. Либо вовсе извращаться с записью изменением в другую таблицу и синхронным переносом их в основную с клиента - но это уже из серии экзотики.
30 мар 19, 15:06    [21847826]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Dimitry Sibiryakov
Member

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

superspy2019
Именно использование snapshot на чтение вынуждает СУБД хранить версии записей и потом их
чистить.

Не вынуждает. Читающая snapshot транзакция версий не создаёт.

superspy2019
Read_committed readonly транзакция не вынуждает собирать версии, но
потребует заблокировать нужные записи

Не потребует. Чтение ничего не блокирует.

superspy2019
Причем Firebird (знаю только про 2.5) по умолчанию вопреки канонам
использует вариант no_record_version

Firebird использует тот вариант, который ей предписывает разработчик приложения в
Transaction Parameters Block. Причём реально "по умолчанию" это concurrency, то есть
"snapshot".

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 31
Dimitry Sibiryakov,
Вы не правы по всем трем пунктам. Но так как читать вы не умеете и в предметную область вникать не можете, в чем-то вас убеждать я не буду
30 мар 19, 15:28    [21847835]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28212
superspy2019
Read_committed readonly транзакция не вынуждает собирать версии, но потребует заблокировать нужные записи, иначе нельзя гарантировать консистентность, о чем абсолютно точно сказал H5N1. Причем Firebird (знаю только про 2.5) по умолчанию вопреки канонам использует вариант no_record_version, что приводит к двухфазной блокировке и дает исключение при попытке прочитать неконсистентный набор.

честное слово, большей ахинеи про версионность в ФБ я нигде не читал.

какие еще, ..., каноны? Где "по умолчанию использует no_rec_version"? Какая еще "двухфазная блокировка"?
Вы не просто бредите, вы в другой вселенной находитесь.
30 мар 19, 15:40    [21847841]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28212
superspy2019
Вы не правы по всем трем пунктам. Но так как читать вы не умеете и в предметную область вникать не можете, в чем-то вас убеждать я не буду

гражданин, я вас уверяю - вы несёте ахинею, и при этом считаете её истиной. Это ВЫ читать не умеете, о чем и заявляете с непомерным пафосом.

А чтобы не подвергнуться аналогичным обвинениям с вашей стороны, на всякий случай сообщу, что ibase.ru это мой сайт, и я и есть kdv, который написал тучу статей про версионность, сборку мусора, транзакции, и так далее.
И если вы собираетесь на эту тему что-то еще брякнуть, то рекомендую ПЕРЕЧИТАТЬ эти самые статьи.
30 мар 19, 15:43    [21847844]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 60245
kdv> гражданин, я вас уверяю - вы несёте ахинею, и при этом считаете её истиной.

Вы, Шариков, чепуху говорите. И возмутительнее всего
то, что говорите её безапелляционно и уверенно. (с)

Не мешай человеку буйно ламерствовать.

Posted via ActualForum NNTP Server 1.5

30 мар 19, 15:51    [21847852]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Dimitry Sibiryakov
Member

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

Кстати о птичках:
[quot superspy2019]
Причем Firebird (знаю только про 2.5) по умолчанию вопреки канонам использует вариант
no_record_version, что приводит к двухфазной блокировке и дает исключение при попытке
прочитать неконсистентный набор.
[quot]
Умолчание для read_committed это no_rec_version + wait, которое (до некоторой
степени) позволяет эмулировать каноническое поведение Оракула с его lost writes.
Так что насчёт канонов ты тоже неправ.

А для получения исключений неопытный (криворукий) разработчик должен явно установить
read_committed + nowait, что уже совсем не умолчание.

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 31
kdv
честное слово, большей ахинеи про версионность в ФБ я нигде не читал.

какие еще, ..., каноны? Где "по умолчанию использует no_rec_version"? Какая еще "двухфазная блокировка"?
Вы не просто бредите, вы в другой вселенной находитесь.

kdv
гражданин, я вас уверяю - вы несёте ахинею, и при этом считаете её истиной. Это ВЫ читать не умеете, о чем и заявляете с непомерным пафосом.

А чтобы не подвергнуться аналогичным обвинениям с вашей стороны, на всякий случай сообщу, что ibase.ru это мой сайт, и я и есть kdv, который написал тучу статей про версионность, сборку мусора, транзакции, и так далее.
И если вы собираетесь на эту тему что-то еще брякнуть, то рекомендую ПЕРЕЧИТАТЬ эти самые статьи.


Добрый день.
Если я в чем-то заблуждаюсь, то охотно выслушаю истину в последней инстанции. Я в общем-то, за этим на форум и обратился.
И злиться совершенно не обязательно (если это, конечно, не ваш режим по-умолчанию), я к этому никого не принуждаю. Сведения про работу с транзакциями черпаю отсюда: http://www.ibase.ru/files/firebird/langref25rus/index.html#transaction.

Цитирую:
NO RECORD_VERSION (значение по умолчанию) является в некотором роде механизмом двухфазной блокировки. В этом случае транзакция не может прочитать любую запись, которая была изменена параллельной активной (неподтвержденной) транзакцией.
Если указана стратегия разрешения блокировок NO WAIT, то будет немедленно выдано соответствующее исключение.

Если вы пришли сказать что-то конструктивное, интересно будет услышать комментарий в контексте ваших сообщений - в чем конкретно я ошибся.
30 мар 19, 16:50    [21847877]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
Dimitry Sibiryakov
А для получения исключений неопытный (криворукий) разработчик должен явно установить
read_committed + nowait, что уже совсем не умолчание.


Вы совершенно забыли о том, что в режиме No_Record_Version + Wait исключение вызывается, если параллельная транзакция не была отменена по истечению таймаута. Или не забыли, а явно пытаетесь вводить в заблуждение. Не знаю.
30 мар 19, 16:55    [21847880]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
vvvait
Member

Откуда:
Сообщений: 80
Нужно что-то вроде этого?

select r.NAME, f.NAME, t.RDB$TRIGGER_NAME
from (select RDB$RELATION_NAME
      from RDB$RELATIONS
      where RDB$RELATION_NAME = 'RDB$RELATIONS'
      union all
      select null
      from RDB$DATABASE) as r(NAME)
left join (select RDB$FIELD_NAME
           from RDB$RELATION_FIELDS
           where RDB$RELATION_NAME = 'RDB$RELATIONS'
           union all
           select null
           from RDB$DATABASE) as f(NAME) on r.NAME is null
left join RDB$TRIGGERS t on t.RDB$RELATION_NAME = 'RDB$RELATIONS' and f.NAME is null and r.NAME is null


но профессионалы для передачи таких структур используют XML или JSON
30 мар 19, 17:02    [21847882]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
vvvait
Нужно что-то вроде этого?

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

vvvait
но профессионалы для передачи таких структур используют XML или JSON

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

Откуда:
Сообщений: 31
vvvait
но профессионалы для передачи таких структур используют XML или JSON


Если конечно эта фраза была написана в отношении формата получаемых от БД данных.
Могу придумать только собирать схему вложенными for select и суспендить из хранимой процедуры. Очень интересно посмотреть на производительность в деле. Очень сомневаюсь
30 мар 19, 17:20    [21847890]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
vvvait
Member

Откуда:
Сообщений: 80
для большего кол-ва полей расписывать не стану
select r.NAME, r.ID, f.NAME, f.ID, t.RDB$TRIGGER_NAME, t.RDB$TRIGGER_TYPE
from (select RDB$RELATION_NAME, RDB$RELATION_ID
      from RDB$RELATIONS
      where RDB$RELATION_NAME = 'RDB$RELATIONS'
      union all
      select null, null
      from RDB$DATABASE) as r(NAME, ID)
left join (select RDB$FIELD_NAME, RDB$FIELD_ID
           from RDB$RELATION_FIELDS
           where RDB$RELATION_NAME = 'RDB$RELATIONS'
           union all
           select null, null
           from RDB$DATABASE) as f(NAME, ID) on r.NAME is null
left join RDB$TRIGGERS t on t.RDB$RELATION_NAME = 'RDB$RELATIONS' and f.NAME is null and r.NAME is null


в выгрузке в xml нет никаких сложностей, отчеты мы например в виде готового html сразу из базы получаем
30 мар 19, 17:21    [21847891]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
vvvait
Member

Откуда:
Сообщений: 80
с left join-ами - плохой путь. в какой-то момент можно уперется в ограничение на размер кортежа 64 кб, придётся всё к блобам приводить
30 мар 19, 17:24    [21847893]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
vvvait
Member

Откуда:
Сообщений: 80
хранимая процедура не нужна, можно использовать union all
30 мар 19, 17:25    [21847895]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
vvvait
Member

Откуда:
Сообщений: 80
вот пример запроса
select cast('<?xml version="1.0" encoding="Windows-1251" ?>' as varchar(1000))
from RDB$DATABASE
union all
select cast('<root day="'||c.FULL_DATE||'" shift="'||s.NAME||'" filter="'||ef.NAME||'" >' as varchar(1000))
from RDB$DATABASE
join CALENDAR c on c.ID_DAY = :"Дата"
join SHIFTS s on s.ID_SH = :"Смена"
join EMPLOYEE_FILTER ef on ef.ID_F = :"Фильтр" 
union all
select cast('<nodes>' as varchar(1000))
from RDB$DATABASE
union all
select cast('  <node '||
                 'fio="'||(select OUT_STR from XML$FORMAT_STR(e.FULL_NAME))||'" '||
                 'rang="'||(select OUT_STR from XML$FORMAT_STR(e.RANG))||'" '||
                 'tab="'||(select OUT_STR from XML$FORMAT_STR(e.TABEL))||'" '||
                 'dep="'||(select OUT_STR from XML$FORMAT_STR(coalesce((select NEW_NAME from TABEL$GET_FULL_DEP(eh.ID_EG, null, 0)),'')))||'" '||
                 'wtt="'||(select OUT_STR from XML$FORMAT_STR(wtt.NAME))||'" '||
                 'dur="'||cast(coalesce(fi.CALC_INTERVAL,0) as numeric(15,4))||'" />' as varchar(1000))
from EMPLOYEE e
join TABEL$EMPLOYEE_HISTORY eh on eh.ID_EMP = e.ID_EMP and eh.ACTUAL = 1 
join EMPLOYEE_FILTERED ef on ef.ID_EMP = e.ID_EMP and ef.ID_F = :"Фильтр"
join TABEL$FORECAST fc on fc.ID_EMP = e.ID_EMP
                      and fc.ID_DAY = :"Дата"
                      and fc.ID_TF = (select ID_TF from TABEL$GET_LAST_DOC(:"Дата", e.ID_EMP, 1))
join TABEL$FORECAST_INTERVALS fi on fi.ID_TF = fc.ID_TF
join TABEL$WORK_TIME_TYPES wtt on wtt.ID_WTT = fi.ID_WTT and wtt.ON_TER = 1
join TABEL$SHIFT_INTERVALS si on si.ID_SI = fi.ID_SI and si.ID_SH = :"Смена"
union all
select cast('</nodes>' as varchar(1000))
from RDB$DATABASE
union all
select cast('</root>' as varchar(1000))
from RDB$DATABASE
30 мар 19, 17:29    [21847899]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Dimitry Sibiryakov
Member

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

superspy2019
Вы совершенно забыли о том, что в режиме No_Record_Version + Wait исключение вызывается,
если параллельная транзакция не была отменена по истечению таймаута.

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

Posted via ActualForum NNTP Server 1.5

30 мар 19, 17:46    [21847903]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10020
H5N1
superspy2019
Не знаю, с чего вы взяли, что я пришел сюда что-то показывать. Я пришел за умным советом. А вы, батенька, даете ужасные советы и пытаетесь троллить, выводя меня на эмоции.

ну ты нашел место, куда прийти за умным советом. лет 10 наблюдаю за веткой фб, в лучшем случае эти добрые люди советуют убиться о стену


ну не всем и не всегда. Только когда упёртные попадаются.
И вообще чего это ты в чужой огород зашёл? Слово Оракуль что-ли увидел? Так его вроде здесь не ругают.

H5N1
в запрос вникать лень, но на счет тразакции учти, фб не оракл. read committed там не гарантирует консистентного набора. 1 или 4 запроса вернут кашу с одинаковой вероятностью. судя по всему тебе нужна snapshot транзакция и 4 запроса в рамках снепшот транзакции


Во-первых в 4.0 read committed уже выдаёт согласованный результат на уровне запроса
Во-вторых ничего страшного в shapshot транзакции нет, если её не держать активной часами.
30 мар 19, 17:46    [21847904]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Симонов Денис
Member

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

у тебя есть следующие варианты:

- взять готовую ORM (там всё за тебя уже сделано) и научиться работать с ней
- один большой select запрос, результат которого надо самостоятельно распихивать по коллекциям сущностей (делать ORM самому)
- много select запросов в snapshot в snapshot транзакции с распихиванием результатов в коллекции сущностей
- собирать JSON/XML на сервере и передавать как BLOB

Последнее кстати не так уж сложно сделать. Я в качестве эксперимента собирал UDR которая результат запроса закатывала в JSON
30 мар 19, 18:00    [21847912]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
m7m
Member

Откуда: Украина, Мариуполь
Сообщений: 1347
Симонов Денис
superspy2019,

у тебя есть следующие варианты:

- взять готовую ORM (там всё за тебя уже сделано) и научиться работать с ней
- один большой select запрос, результат которого надо самостоятельно распихивать по коллекциям сущностей (делать ORM самому)
- много select запросов в snapshot в snapshot транзакции с распихиванием результатов в коллекции сущностей
- собирать JSON/XML на сервере и передавать как BLOB

Последнее кстати не так уж сложно сделать. Я в качестве эксперимента собирал UDR которая результат запроса закатывала в JSON

Думаю вариант
4-ре select запроса (по одному на каждую таблицу)
возможно что и получится
30 мар 19, 18:07    [21847916]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Симонов Денис
Member

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

ну всякие ORM в большинстве случаев выбирает 2-ой, если только не используется отложенная загрузка свойств
30 мар 19, 18:10    [21847918]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
vvvait
вот пример запроса


Спасибо великое! Попробовал на примере for select в лоб составлять xml - крайне утомительно писать и еще более утомительно добиться потом валидации
30 мар 19, 18:16    [21847919]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

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

у тебя есть следующие варианты:

- взять готовую ORM (там всё за тебя уже сделано) и научиться работать с ней
- один большой select запрос, результат которого надо самостоятельно распихивать по коллекциям сущностей (делать ORM самому)
- много select запросов в snapshot в snapshot транзакции с распихиванием результатов в коллекции сущностей
- собирать JSON/XML на сервере и передавать как BLOB

Последнее кстати не так уж сложно сделать. Я в качестве эксперимента собирал UDR которая результат запроса закатывала в JSON


Да, спасибо, я склоняюсь больше к селектам, обернутым в снапшот. Оно хотя бы будет человечески выглядеть в результате
30 мар 19, 18:19    [21847920]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Симонов Денис
Member

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

ну его этот xml, уж лучше json
30 мар 19, 18:26    [21847924]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
Dimitry Sibiryakov
superspy2019
Вы совершенно забыли о том, что в режиме No_Record_Version + Wait исключение вызывается,
если параллельная транзакция не была отменена по истечению таймаута.

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


Уважаемый, фраза "если параллельная транзакция не была отменена по истечению таймаута" эквивалентна фразе "параллельная транзакция закоммитила изменения". У меня стойкое ощущение, что вы не воспринимаете параллельную работу многих потоков в БД как необходимость. При плотных update по таблице с какой-нибудь статистикой вы не сможете нормально выполнить ожидающий read_committed. У вас будет альтернатива в виде использования snapshot или более строгого уровня изоляции, либо более оптимального способа read_committed + rec_version - но он станет грубейшей ошибкой при чтении более 1 таблицы в одной транзакции, как вы это предлагали в ваших лучших традициях индусской практики ранее.
30 мар 19, 18:27    [21847925]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Симонов Денис
Member

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

он никогда такого не предлагал. Более того он обычно советует везде и всегда использовать snapshot, а про существование RC вообще забыть.
30 мар 19, 18:40    [21847929]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
vvvait
Member

Откуда:
Сообщений: 80
Симонов Денис, json хуже, там запятые ставить нужно, хотя в новых версиях можно и в конце перечисления запятую ставить.
XML лучше тем, что потом можно шаблоном крутить как угодно и агрегаты посчитать и группировки с сортировками на клиенте, чтобы сервер разгрузить.
30 мар 19, 18:53    [21847937]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Dimitry Sibiryakov
Member

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

superspy2019
"если параллельная транзакция не была отменена по истечению таймаута" эквивалентна фразе
"параллельная транзакция закоммитила изменения".

Уверен? Сам я никогда не использовал такую экзотику как read_committed no_rec_version, но
когда с ним экспериментировал Таблоид, ему удавалось получить бесконфликтное обновление
одной записи при двух параллельных транзакциях. Вот при трёх уже действительно получался
облом.

superspy2019
У вас будет альтернатива в виде использования snapshot или более строгого уровня изоляции,
либо более оптимального способа read_committed + rec_version

Второй способ никоим образом не является "более оптимальным". Как уже сказали, я всегда
советую забыть о read committed как о страшном сне, который в Борланде кривовато прилепили
к Interbase чтобы их BDE мог с ним сносно работать.

Posted via ActualForum NNTP Server 1.5

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

Откуда: iBase.ru
Сообщений: 28212
superspy2019
NO RECORD_VERSION (значение по умолчанию) является в некотором роде механизмом двухфазной блокировки.

Если честно, то я не очень понимаю, что имел в виду Денис Симонов, когда писал про эту самую "двухфазную блокировку", причем "в некотором роде".
Про no_rec_version у меня на сайте написано в описании транзакций
http://www.ibase.ru/ibtrans/
и человек достаточно подробно расписал в
http://www.ibase.ru/norecver

кроме того, насчет "по дефолту", я вам сообщу, что "по дефолту" этот дурацкий режим использовался до BDE 4.1, пока я не указал на это Borland, и в ODBC до версии 1.52 пока я не указал на это разработчикам ODBC, и вроде бы до сих пор используется в .Net, хотя я с Иржи даже поругался на эту тему в 2012 году. Но это его личные проблемы.

В компонентах прямого доступа no_rec_ver практически никогда не использовался по дефолту для read committed, потому что тогда уже все всё понимали.
superspy2019
либо более оптимального способа read_committed + rec_version - но он станет грубейшей ошибкой при чтении более 1 таблицы в одной транзакции

это станет "грубейшей ошибкой" только если вы не понимаете, что такое read committed. Оно ПО ОПРЕДЕЛЕНИЮ предполагает нестабильное чтение даже из ОДНОЙ таблицы.
superspy2019
Если вы пришли сказать что-то конструктивное

я вам пришел сказать, что вы не понимаете того, что пытаетесь обсуждать. И хамить мне не надо по поводу конструктива. Я с InterBase работаю с 1994 года, и в версионности понимаю уж побольше чем вы. Перечитайте еще раз статьи на ibase.ru.
Когда мне было непонятно про версионность и транзакции, я имеющийся на тот момент материал перечитывал по 4-5 раз, нисколько этого не стыдясь. Чего и вам советую.
superspy2019
Уважаемый, фраза "если параллельная транзакция не была отменена по истечению таймаута" эквивалентна фразе "параллельная транзакция закоммитила изменения".

а по-моему ваша фраза - сивый бред. Если транзакция не завершена, то она никак не могла ни закоммиттить изменения, ни быть отмененной по роллбэку. Вы тут что-то путаете с MS SQL, видимо.
superspy2019
У меня стойкое ощущение, что вы не воспринимаете параллельную работу многих потоков в БД как необходимость.

у меня стойкое ощущение, что вы воспринимаете параллельную работу многих потоков в БД как нечто отличное от параллельной работы с БД нескольких отдельных пользователей. При том, что в такой работе нет никакой разницы, совершенно.
30 мар 19, 21:32    [21847995]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10020
kdv
Если честно, то я не очень понимаю, что имел в виду Денис Симонов, когда писал про эту самую "двухфазную блокировку", причем "в некотором роде".


ну это придумала Хелен. У меня вряд ли бы хватило фантазии писать про какие-то двухфазные блокировки. Но оно там явно в переносном смысле написано. Может не совсем корректный перевод.
30 мар 19, 21:40    [21848002]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
vvvait
Симонов Денис, json хуже, там запятые ставить нужно, хотя в новых версиях можно и в конце перечисления запятую ставить.
XML лучше тем, что потом можно шаблоном крутить как угодно и агрегаты посчитать и группировки с сортировками на клиенте, чтобы сервер разгрузить.


На самом деле не лучше и не хуже в плане удобства работы, если json корректный. Зато объем текста куда меньше. Конечно, xsl преобразования и всевозможные способы валидации на стороне XML, но на практике настолько редко это все нужно на самом деле. Красивый отчет можно построить на чем угодно. Но все зависит от задач, конечно
31 мар 19, 01:00    [21848112]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
kdv
честное слово, большей ахинеи про версионность в ФБ я нигде не читал.

kdv
Вы не просто бредите, вы в другой вселенной находитесь.

kdv
гражданин, я вас уверяю - вы несёте ахинею, и при этом считаете её истиной. Это ВЫ читать не умеете, о чем и заявляете с непомерным пафосом.

kdv
И если вы собираетесь на эту тему что-то еще брякнуть, то рекомендую ПЕРЕЧИТАТЬ эти самые статьи.



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

kdv
я вам пришел сказать, что вы не понимаете того, что пытаетесь обсуждать. И хамить мне не надо по поводу конструктива


Сначала я подумал, что у вас дичайшая жгучая звездная болезнь. Потом понял, что просто отсутствуют зачатки воспитания и вежливости. Теперь стал абсолютно уверен в том, что у вас весеннее обострение и запущенный психоз. Думаю, вам стоит обратиться за квалифицированной помощью, пока не все потеряно... Наверное, столько желчи и злости на этом ресурсе из-за того, что его адепты ничем не хуже
31 мар 19, 01:11    [21848116]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
m7m
Member

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

Мда, с таким восприятием критики ты долго не задержишься здесь :(
31 мар 19, 09:02    [21848141]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Ivan_Pisarevsky
Member

Откуда: НН
Сообщений: 8372
Модератор: Господа, предлагаю сбавить обороты. У нас не медицинский форум, раздача диагнозов может привести только к зачистке подобных раздач. Благодарю за понимание.
31 мар 19, 12:37    [21848206]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28212
superspy2019,

вы свои сообщения перечитайте. Потом перечитайте статьи про версионность. Если что непонятно, я объясню. Но пока ваши выводы от прочитанного почти во всём неверны.
31 мар 19, 12:55    [21848216]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

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

вы свои сообщения перечитайте. Потом перечитайте статьи про версионность. Если что непонятно, я объясню. Но пока ваши выводы от прочитанного почти во всём неверны.


Спасибо! Я сохранил ссылки - обязательно прочитаю.
31 мар 19, 16:00    [21848295]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 16648
Извините, лень весь топик читать.
По существу, если автора устраивает "как в 1С", то делать больше ничего и не нужно.
superspy2019
В аналоги могу лишь привести 1С : если сделать подобный запрос с итогами, с помощью нескольких выборок на разных уровнях иерархии можно обойти как шапки документов, так и табличные части. Здесь главным критерием является то, что запрос на сервер оформляется один. Код выглядит как обход дерева.
Если хоть немного вникнуть в то, как 1С работает с данными, то сразу становится ясно, что "итоги" - это результат обработки уже полученных данных сервером приложений 1С, поскольку никаких древовидных "итогов" в SQL не наблюдается.
1 апр 19, 16:11    [21849100]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4      [все]
Все форумы / Firebird, InterBase Ответить