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


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

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

m7m,

В целом, практически вся работа с СУБД происходит через сеть - вполне возможно, что кроссдоменно с удаленных площадок. Среднее время на запрос - 5-500 мс. Как советует архитектор выше - делать запросы в цикле, - уже накодили и теперь приходится все просто переписывать. Благо я гибче и инструментов у меня больше. И если задачу синхронизации с БД десятками тысяч insert / update / update or insert я эффективно решаю объединением в execute block скрипты (уменьшая количество запросов в сотник раз), то вот запрос структуры из разных таблиц сделан, на мой взгляд, не очень оптимально. В этом и хотелось бы разобраться глубже.

ёёёёё,

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

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


Вы уже продемонстрировали свой уровень, что еще хотите?
99% этого времени клиент в принципе не тратит, так как весь код асинхронный, однако в разрезе на запрос время уходит на ожидание TCP запроса. Я проводил замеры на небольших update, получил разницу между подготовленными с параметрами и текстовыми со случайными значениями запросами на грани статистической погрешности. Все одиночные запросы я параметризую - не из-за безопасности (нет у меня задач вытаскивать работу с SQL наружу, все запросы программируются), а просто потому что удобнее. Вы промахиваетесь с этой темой.

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

В общем, максимум из темы смог выжать запрос



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

Результат

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

Ничего более умного не могу придумать

Dimitry SibiryakovЧтобы Вы таки продемонстрировали свой.


Не знаю, с чего вы взяли, что я пришел сюда что-то показывать. Я пришел за умным советом. А вы, батенька, даете ужасные советы и пытаетесь троллить, выводя меня на эмоции.

H5N1,

Абсолютно верно - выше я этот вопрос озвучил. Либо snapshot с блокированием на запись, либо собирать мусор на версиях. Сложно на самом деле, поэтому вариант нескольких параллельных селектов мне не нравится

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

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

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


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

Про все это я уже говорил выше, здесь вынужден повторяться

m7mХранимая процедура с использованием явных курсоров позволит отказаться от доп.поля POSITION

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

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

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