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

Автор serkondr, 25 октября 2015, 10:13

0 Пользователи и 1 гость просматривают эту тему.

kompilainenn

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

serkondr

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

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

kompilainenn

Таблица БД и Форма в виде таблицы - это две большие разницы
Поддержать разработчиков LibreOffice можно тут, а наш форум вот тут

serkondr

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

kompilainenn

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

serkondr

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

serkondr

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

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

rami

Цитата: serkondr от 30 октября 2015, 19:46За 4 года там накопилось много чего, даже не помню. Основная форма - выдача по нормам. На ней самые большие тормоза.
Там не тормоза, там наглухо приварено... Форма открывается, но зависает при рассчётах :(
Цитата: kompilainenn от 29 октября 2015, 17:13Мне кажется, что увас системная ошибка в проектировании бд
Уже не кажется, так оно и есть. База слишком раздута, много избыточных данных. Например:

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

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

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

kompilainenn

Цитата: rami от 31 октября 2015, 10:26Про каскадные вычисления основной формы пока молчу, там нужно разбираться
да это вообще не должно быть ТАК реализовано
Поддержать разработчиков LibreOffice можно тут, а наш форум вот тут

serkondr

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

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

serkondr

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

kompilainenn

ну вот=) видите, как все просто. нет предела совершенству
Поддержать разработчиков LibreOffice можно тут, а наш форум вот тут