Ускоритель локальной базы .xdb

[Vladzimir]

Посвящается всем у кого большое количество заказов и/или товаров.
Главная причина — не размер и не фрагментация, а отсутствующие индексы:
- DocumentRows.RowID — 326 908 уникальных значений, но индекса нет. Программа обращается к нему отдельно для каждой партии.
- DocumentRows.SeriesID — используется при проведении, но не индексирован.
- DocLinks.RelatID — участвует в тяжёлом соединении заказов.
- Documents.DocDate — постоянно используется в расчётах периода.
На тестовой копии:
- поиск по RowID: 425 → 3,4 мс, примерно в 125 раз быстрее;
- запрос заказов: более 90 → около 3 секунд;
- расчёт за период после индекса даты: 1828 → 14 мс;
- сжатие уменьшило файл лишь на 0,65%, поэтому регулярное «резание» лечит симптом, а не причину.

Как запустить:
1. Распакуйте ZIP на компьютере.
2. Закройте «Предприниматель 4» на всех компьютерах.
3. Перетащите файл .mdb или .xdb мышью на run-optimizer.bat.
4. Рядом с базой появится имя.optimized.mdb.

[dmitry]

Браво. Снимаю шляпу.

Правда, многолетние наблюдения и замеры с реальными БД показали, что просто увеличение числа индексов может привести к противоположному результату - резкому замедлению.
Я думаю, что при добавлении еще какого-то индекса MsJet.dll, сравнивая планы выполнения запроса, строит слишком много планов, какой-то лимит по оценке затрат превышен, и он со словами: "Все равно у меня ничего не получится" переходит к сканированию таблиц.
Поэтому я предусмотрел персональный подход (у каждой БД своя статистика: у кого-то один склад, одно значение OfficeID, у кого-то в рознице один покупатель, у кого-то 10 услуг, у кого-то 10 тыс. товаров).
Клавиши Ctrl+F9, ткнуть в ячейке нужной таблицы - появится кнопочка:

1.png (33.37 КБ) Просмотров: 413

Можно чекбоксами включать/отключать индексы:

2.png (41.92 КБ) Просмотров: 413

После каждого изменения проводить замеры:

3.png (16.93 КБ) Просмотров: 413

А вообще - с большой БД лучше перейти на SQL Server.

[Vladzimir]

Браво. Снимаю шляпу.

Этот анализ сделал не я, а Codex моделью Astra.

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

Я не очень хорошо знаком с MS Access, но в других СУБД, с которыми я работал, например MySQL и SQLite, для полей, используемых в связях между таблицами, обычно рекомендуют создавать индексы. Насколько я понимаю, это достаточно стандартная практика. Разумеется, это не означает, что чем больше индексов, тем лучше - лишние индексы тоже имеют свою цену, особенно при записи и обновлении данных.

А вообще - с большой БД лучше перейти на SQL Server.

До объёмов в десятки миллионов записей здесь ещё далеко, а текущая СУБД с задачей справляется. Поэтому не совсем вижу, какую практическую выгоду в данном случае даст SQL Server, особенно если можно обойтись без дополнительных затрат. К тому же серверная СУБД означает дополнительные накладные расходы на развёртывание и сопровождение, а в моём случае ещё и некоторое снижение удобства.

[dmitry]

Для понимания: какой размер БД? (виден в Файл / Открыть БД)
Какое время показывает при проведении накладной? (как на моем скриншоте)

[Vladzimir]

Для понимания: какой размер БД? (виден в Файл / Открыть БД)
Какое время показывает при проведении накладной? (как на моем скриншоте)

161 Мб
46 позиций в накладной - 0,73 сек

[Deks]

А вообще - с большой БД лучше перейти на SQL Server.

Добрый день! Подскажите пожалуйта, работаем через SQL Server, при поиске товаров (с удаленных компьютеров) и при формировании отчетов, остатков, при проведение продаж приходится очень долго ждать. Провайдеры на подключенных компьютерах разные, скорость максимальная, везде оптика.

[dmitry]

Для каждого пункта (поиск товара - по названию или сканером штрих-кодов, формирование отчетов, проведение накладной) есть отдельные решения.
Напишите мне в Телеграм +380 682202152 https://t.me/predpr4 с удаленного компьютера. Подключусь через Anydesk, изучу и оптимизирую.