| |
|
|
| | Мне очень нужно кардинально повысить быстродействие (подгрузку записей в формах). Очень нужна ваша помощь. Жду любых практичных советов, идей.
1. Есть база на MS Access 2003-2007.
2. Базы (таблица) по клиентам + база (таблица) по взаимодействиям с ними (подчиненная форма). Сейчас там тысячи позиций по клиентам + более сотни тысяч записей по взаимодействиям.
3. База разделена на табличную часть и базу с запросами-формами.
4. База используется несколькими пользователями одновременно. Каждый запускает свою копию базы с запросами-формами.
5. При перелистывании в форме записей по клиентам проходит 10-20 секунд. Что, конечно, нереально долго.
Что сделать, чтобы скорость сократилась до долей секунды? Повторюсь, вопрос очень критичный.
P.S. Есть еще одна база. Там 90 тыс.клиентов и 350 тыс.взаимодействий. Там та же проблема.
Заранее спасибо! | |
| |
| |
| |
|
|
| | может нормальный поиск сделать, динамический
=========
раз листают --значит ищут
===============
какова цель работы
--только просмотр и распечатка выбранного
--корректировка | |
| |
| |
| |
|
|
| | 1. Чуть подробнее про динамический поиск. Что это?
2. "Раз листают - значит ищут" - не понял смысл сообщения.
3. И просмотр, и корректировка. | |
| |
| |
| |
 44 Кб. |
|
| | если только поиск ---вот пример поиска
========
поиск не помешает и при корректировке | |
| |
| |
| |
|
|
| | Ещё раз посмотрел все формы. Самые большие зависания - когда источником данных для формы является каскад запросов.
Таблица ==> Запрос ==> Запрос + запрос ==> Форма.
Как ускорить действие базы в этом случае, если такой каскад запросов необходим... Можно ли как-то уменьшить задачу ему, например, если в абсолютном большинстве случаев в этих запросах используется лишь малая часть табличных данных (то есть выборки делаются по данным, скажем, последнего полугода... а вообще в базе данные за несколько лет)? | |
| |
| |
| |
|
|
| | я выборку делала по принципу записи во временную таблицу на локальном компе
select klient, tovar, mec. sum(kol), sum(summa) into rab1 in 'c:\temp\rab1.mdb'
where god=2014
group by klient, tovar, mec
|
далее итоги более высокого уровня и отчеты в разных разрезах с этой временной таблицы, основная таблица не занимается | |
| |
| |
| |
|
|
| | как вариант ускорения всего процесса - RDP.
эффект будет налицо - сам так делал. | |
| |
| |
| |
|
|
| |
Как ускорить действие базы в этом случае, если такой каскад запросов необходим... Можно ли как-то уменьшить задачу ему, например, если в абсолютном большинстве случаев в этих запросах используется лишь малая часть табличных данных (то есть выборки делаются по данным, скажем, последнего полугода... а вообще в базе данные за несколько лет)?
|
можно, немного усложнив себе жизнь, сделать 2 таблы - "оперативные" даннеы (последние пол года) и полная табла. данные при внесении/редактировании заносятся в обе таблы.
желательно сохранив синхронность ключа. (ну или в оперативной поле кобч заполнять самому, согласно полной таблы.
и раз в период чистить оперативную таблу.
т.е. если период попадает в оперативную 90-95% запросов - все летает по "оперативной" табле. отсальные 5-10% радостно ждут около дымящегося компа 
вариант № 2.
продумать логику работы клиента.
если менагер Вася работает с магазином № 2, 7, 15 - то инфа по магазинам 10, 66,88 ему не нужна.
при запуске пишем сообщение "Идет загрузка данных" и во временные таблы прогружаем инфу по Васиным магазинам, сэтими временными таблами Вася спокоуо раотает в течении дня.
можно добавить таймер на главную форму который будет подгружать данные во временные таблы если данные в них изменили другие юзеры. | |
| |
| |
| |
|
|
| | Вообще конечно грамотный поиск, а не вывод всего что бы народ "листал"
Но вообще "Там 90 тыс.клиентов и 350 тыс.взаимодействий", это довольно много для MSA. | |
| |
| |
| |
|
|
| | хотелось бы увидеть базы
вопрос 1--- сложно оценить потребный поиск
--90т клиентов требуют поиска по клиент-дата/период-операция(и другие поля....)
--для выбранного клиента показать подчиненные строки по дате/период......
вопрос 2--что делают эти несколько пользователей
--только смотрят/печатают---не допускать прямой доступ
--корректируют ---для этого можно в некоторых формат допустить прямой доступ, но поиск обязателен
например
--ленточная форма с поиском без прямого доступа к записям
--при клике на выбранной строке --переход на форму-корректировку | |
| |
| |
| |
|
|
| | короче базу в студию
(ХР формат) | |
| |
| |
| |
|
|
| | Базы (таблица) по клиентам + база (таблица) по взаимодействиям с ними (подчиненная форма). Сейчас там тысячи позиций по клиентам + более сотни тысяч записей по взаимодействиям.
По поводу главных и подчиненных форм:
Для аксесса давно уже использую такой порядок:
Записи основной таблицы - в главной форме.
На событие главной формы Form_Current создается источник данных для подчиненной формы.
То есть, в конструкторе "подчиненные поля" и "основные поля" не заполняются. Поскольку, как я понял, они читают ВСЮ таблицу, а потом фильтруют ее по необходимому полю.
База используется несколькими пользователями одновременно. Каждый запускает свою копию базы с запросами-формами.
Перелезайте на SQL, да хоть и на локальном компьютере.
у меня есть подобные по размерам таблицы
данные - на PostgreSQL
Все летает. | |
| |
| |
