Cервер HSQLDB 1.8.0.10 - как избавиться от тормоза?

[kompilainenn]

а вы данные цепляете из форм что ли? да еще по цепочке? а не лучше ваять запросы на основе ТАБЛИЦ и уже из запросов формировать ОДНУ форму?

[serkondr]

Может я написал сумбурно.
Форма у меня состоит из элементов типа "таблица".
Для содержимого каждого элемента типа "таблица" использую запросы, либо таблицы БД, если требуется ввод данных.
Все элементы формы имеют связи по цепочке, поэтому отображаемое содержимое следующего элемента формы зависит от положения указателя предыдущего элемента.

Просто элементы форм тоже называют формами (субформами), вот и получается путаница.

[kompilainenn]

Таблица БД и Форма в виде таблицы - это две большие разницы

[serkondr]

Да, конечно, прошу извинить за сумбур.
Так вот, можно-ли как-то реализовать вышеописанную схему работы элементов формы и избежать умножения количества записей в запросах от элемента к элементу?

[kompilainenn]

Я бы посмотрел на файл или схему бд. Мне кажется, что увас системная ошибка в проектировании бд

[serkondr]

Втолкал данные в локальный файл БД, чтоб выложить. И оказалось, его размер велик для форума. А ссылки тут удаляются.

[serkondr]

Склад по нормам-локальная версия.odb

За 4 года там накопилось много чего, даже не помню. Основная форма - выдача по нормам. На ней самые большие тормоза.

[rami]

За 4 года там накопилось много чего, даже не помню. Основная форма - выдача по нормам. На ней самые большие тормоза.

Там не тормоза, там наглухо приварено... Форма открывается, но зависает при рассчётах

Мне кажется, что увас системная ошибка в проектировании бд

Уже не кажется, так оно и есть. База слишком раздута, много избыточных данных. Например:

1. таблица Метизы_база — в ней 22010 строк, 18 столбцов. Запрос Список метизов показывает, что есть 776 оригинальных метизов, если запрос Список метизов превратить в таблицу и каждому метизу присвоить IDметиз , то в таблице Метизы_база можно пять столбцов описывающих метизы заменить на один IDметиз — объём таблицы сократится примерно на четверть. Для вас лично эта таблица слишком велика, чтобы её читать (если читать со скоростью одна строка в секунду, на всю таблицу уйдёт 6 - 7 часов), а компьютеру лирические описания метизов ни к чему.

2. не оптимальная типизация данных: в таблице Метизы_база поле ves-st имеет 9 (девять!) знаков после запятой, а поля prih-st и ras-st (я так понимаю приход и расход в штуках) имеют пять знаков после запятой, другие поля тоже имеют не оптимальный тип. В Base есть возможность точно настроить типы данных и этим надо пользоваться для сокращения объёма базы.

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

[kompilainenn]

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

да это вообще не должно быть ТАК реализовано

[serkondr]

Доброго времени суток!
Спасибо за ответы.
По поводу оптимизации объёма данных - мне это советовали в самом начале ещё в 2011 г. Я пробовал вместо одной таблицы сделать несколько со связями через ID, всё получалось красиво. Но был удивлён. когда такая оптимальная структура стала существенно тормозить в запросах. Оказалось, что гораздо быстрее обрабатываются громоздкие таблицы, но при меньшем количеством таблиц и связей между ними. Понимаю, что неправильно, но другого выхода не нашёл. Те, кто мне советовал, не имели дела с HSQLDB, и сразу сказали, чтоб я уходил на 1С, на чём разговор и закончился.

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

[serkondr]

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

[kompilainenn]

ну вот=) видите, как все просто. нет предела совершенству