Как уменьшить растущий размер файла доступа?

Question

Итак, на моем рабочем месте у них огромный файл доступа (используется с MS Access 2003 и 2007). Размер файла составляет около 1,2 ГБ, поэтому для его открытия требуется некоторое время. Мы не можем удалить ни одну из записей, и у нас есть более 100 таблиц (каждый месяц мы создаем еще 4 таблицы, не спрашивайте!). Как мне улучшить это, то есть уменьшить размер файла?

Answer 1

Вы можете сделать две вещи:

• использовать связанные таблицы
• "сжимать" базы данных каждый раз

Связанные таблицы сами по себе не ограничивают общий размер базы данных, но "упаковывают" ее в меньшие, более управляемые файлы. Чтобы посмотреть на это:

'File' menu + 'Get External data' + 'Linked tables'

Связанные таблицы также имеют много преимуществ, таких как возможность сохранять несколько версий подмножества данных и выбор определенного набора с помощью менеджера связанных таблиц.

Сжатие баз данных освобождает пространство, в противном случае теряется, поскольку различные операции CRUD (Вставить, Удалить, Обновить ...) фрагментируют хранилище Он также перегруппирует таблицы и индексы, делая поиск более эффективным. Это сделано с

  'Tools' menu + 'Database Utilities' + 'Compact and Repair Database...'

Answer 2

Вы действительно выходите за пределы ограничений MS Access - знаете ли вы, что размер файла не может превышать 2 ГБ?

Полагаю, вы уже проверили данные на предмет возможного экономии места за счет дополнительной нормализации? Вы можете «заархивировать» некоторые таблицы за предыдущие месяцы в отдельные файлы MDB, а затем связать их (навсегда или по мере необходимости) с вашей «текущей» базой данных (в этом случае вы действительно выиграете от того, что, вероятно, было бы плохим решением начать новые таблицы для каждого месяца).

Но с таким количеством данных, вероятно, пришло время начать планирование перехода на более емкую платформу.

Answer 3

Вы должны действительно подумать о своей архитектуре БД. Если между таблицами нет никаких ссылок, вы можете попытаться переместить некоторые из них в другую базу данных (один дБ в год :) в качестве краткосрочного решения.

Answer 4

Пара идей «хвататься за соломинку»

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

Посмотрите на индексы и избавьтесь от тех, которые вы не используете. На больших таблицах ненужные индексы могут привести к большим накладным расходам.

Я бы + 2 ^ 64 высказал предположение, что дизайн базы данных немного странный, но ничего такого, что еще не было сказано, поэтому я не буду опровергать эту точку

Answer 5

Добавление большего числа таблиц каждый месяц: это уже сомнительная позиция и кажется подозрительной в отношении нормализации данных.
Если вы сделаете это, я подозреваю, что ваша структура базы данных также неоптимальна в отношении размеров полей, типов данных и индексов. Я действительно начал бы с двойной проверки тех.

Если у вас действительно есть обоснование для ежемесячных таблиц (что я не могу себе представить, опять же), почему бы не иметь 1 бэкэнд в месяц?
Вы также можете иметь на главном сервере, скажем, данные за 3 месяца онлайн, а затем архивную базу данных, куда вы перенесете свои старые записи.
Я использую это для транзакций, с основной таблицей, имеющей около 650 000 записей, и Access очень отзывчив.

Answer 6

хорошо .. Слушайте @Larry и имейте в виду, что в долгосрочной перспективе вам нужно будет найти другую базу данных для хранения ваших данных!

Но в краткосрочной перспективе я весьма обеспокоен этой "4 новыми таблицами в месяц". 4 таблицы в месяц - это 50 в год ... Это, безусловно, звучит странно для каждого "менеджера баз данных" здесь. Поэтому, пожалуйста, сообщите нам: сколько строк, как они построены, для чего они нужны, и почему вам приходится строить таблицы каждый месяц?

В зависимости от того, что вы делаете со своими данными, вы также можете подумать об архивировании некоторых таблиц в виде файлов XML (или даже XLS?). Это может иметь смысл для «исторических» данных, к которым нет необходимости обращаться через отношения, представления и т. Д. Одним из хороших примеров будет список телефонных звонков, собранных из УАТС. Данные могут быть сохранены в виде / загружены из файлов XML / XLS с помощью наборов записей ADODB или методом TransferDatabase