@vgorban

Добрый день, уважаемые коллеги!

Помогите с экспертной оценкой!
Есть приложение на Access. Данные хранятся в одном файле mdb на общем диске. У пользователей установлена клиентская часть с формами, запросами. Одновременно с программой работают в среднем около двадцати пользователей. База данных около 200 Мб. И частенько уже хромает быстродействие.
Но не все таблицы в базе данных на сервере используются одинаково часто. Есть ряд массивных таблиц, к которым обращаются редко.
Вопрос: поможет ли повысить быстродействие, если разделить базу данных на сервере, например, на два файла (вынести в отдельный файл массивные но редко используемые таблицы)?

Спасибо!

0

shanemac51

каковы основные потребности этих 20 пользователей
--мелкая справка(1-2 листа) на выбор
--большая справка по количеству записей или расчетов
--КОРРЕКТИРОВКА

что делают с выборкой
--просто смотрят или печатают
--сохраняют в ексель

какой режим поиска перед выборкой
--просмотр списков
--произвольный

0

@vgorban

Приложение это у меня по принципу CRM-систем. Ядро базы данных - таблица с перечнем клиентов. Остальные таблицы различное инфо о клиентах (контакты, задачи, счета, инфо о доходности). Больше всего пользователи работают с задачами (ставят задачу, редактируют, заносят результат).
Часть, которую хотел бы вынести в отдельный файл, это таблицы с данными о доходности клиентов. Инфо раз в месяц обновляется из других систем. Пользователи могут только просматривать это инфо и формировать отчет в Excel. Одновременно пользователь может работать с информацией по одному клиенту.

0

@V_Monomax

а не проще мигрировать в таком случае на MS sql? 20 пользователей 200 мб, там уже сам движек будет определять прерогативы доступа и использования таблиц, ускорение получите минимум на порядок выше, а то и более и дальнейшее администрирование лучше будет проходить.

0

@Серж_87

в коммерческих целях если использовать, то лучше на другое что-нибудь переходить, так как согласно лицензии в мускуле при использовании есть мелкие неувязочки на сколько я знаю. Например использовать firebird (полностью бесплатен для виндовс), если база будет по локалке только, без веба

1

@V_Monomax

а чем MS SQL Express edition плох? там уже все готово и в отличие от всех остальных может быть сконекчен с Access, да и графическое построение легко осилить, единственное требование это виндовс сервер, но судя по тому что ранее указывалось об общем ресурсе сетевом, то скорее всего там все уже готово.

1

@vgorban

Планирую мигрировать на MS SQL. Но вряд ли это быстро получится - для меня MS sql тема новая. Пробовал использовать встроенный мастер преобразования в формат SQL Server, но заработало с большими глюками. Видимо нужно будет перебирать код, а кода в программе уже не мало.
Поэтому и ищу временное решение для повышения быстродействия.

0

@ltv_1953

Клиентская часть лежит на их компьютерах? Тогда поставьте сервер по мощнее (пара Ксеонов 8 ядерных, база на SAS, можно для ОС SSD поставить). Все пользователи работают в режиме терминал-сервер, их интерфейсы лежат в отдельных папках на сервере. Да и для будущего использования SQL такой сервер и такой режим работы только лучше будет.

0

mobile

200 мегов совсем не тот объем, который может серьезно затормозить работу. По моему опыту тормоза, в порядке влияния, такие:
1. Неудачная структура БД, при которой в запросы вынужденно входят медленно считаемые структуры. Например, в условие Where запросов входит структура типа [поле] in (select [поле] ...). Или в запросах, опять таки вынужденно входит большое количество таблиц. Сортировки в больших запросах также могут хорошо попортить жизнь.
2. Неверная установка индексов или их отсутствие. Или соединение таблиц в запросах не по индексным полям. Или условие запросов составлено так, что индексы не могут использоваться.
3. Формы с обилием списков или полей со списком. Особенно, когда в источнике списков большое количество записей. Формы с таким багажом еле поворачиваются.
4. Большое количество мусора в базе. Надо чистить.

0

@vgorban

mobile, спасибо за советы!
Действительно программа постоянно дорабатыватся, дописывается новый функционал, добавляются окна, и далеко не всегда это делается оптимально.
Еще вот пришла мысль делить данные на оперативные и архивные. Например, история показателей доходности клиентов за текущий год используется и востребована чаще - хранится в одной таблице. За предыдущие годы - в архивной.

0