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

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

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

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

Posted via ActualForum NNTP Server 1.5

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

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

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

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

Posted via ActualForum NNTP Server 1.5

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

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

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

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

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

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

Posted via ActualForum NNTP Server 1.5

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

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

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

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

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

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

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

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

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

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

Posted via ActualForum NNTP Server 1.5

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

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

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

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

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.!
Сообщений: 151
superspy2019
Не знаю, с чего вы взяли, что я пришел сюда что-то показывать. Я пришел за умным советом. А вы, батенька, даете ужасные советы и пытаетесь троллить, выводя меня на эмоции.

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

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

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

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

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

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

Posted via ActualForum NNTP Server 1.5

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

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

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

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]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Firebird, InterBase Ответить