Итак, у меня на рабочем месте у них огромный файл доступа (используется с MS Access 2003 и 2007). Размер файла составляет около 1,2 ГБ, поэтому для открытия файла требуется некоторое время. Мы не можем удалить какие-либо записи, и у нас есть около 100 таблиц (каждый месяц мы создаем еще 4 таблицы, не спрашиваем!). Как улучшить это, т. Е. Уменьшить размер файла?Как уменьшить растущий размер файла доступа?
хорошо .. Послушайте @Larry и имейте в виду, что в долгосрочной перспективе вам придется найти другую базу данных для хранения ваших данных!
Но в краткосрочной перспективе меня очень беспокоит эта «4 новых стола в месяц». 4 таблицы в месяц - 50 в год ... Это, безусловно, звучит странно для каждого «менеджера баз данных» здесь. Поэтому, пожалуйста, сообщите нам: сколько строк, как они построены, для чего они нужны, и почему вы должны создавать таблицы каждый месяц?
В зависимости от того, что вы делаете с вашими данными, вы также можете подумать о архивировании некоторых таблиц как XML-файлов (или даже XLS?). Это может иметь смысл для «исторических» данных, к которым не нужно обращаться через отношения, взгляды и т. Д. Одним хорошим примером может служить список телефонных звонков, собираемых из УАТС. Данные могут быть сохранены как/загружены из файлов XML/XLS с помощью наборов записей ADODB или метода transferDatabase
Я проверил, и его не 4, а ~ 20 + таблицы в месяц. снова, не спрашивайте. –
и каждый месяц мы импортируем новые данные из массового файла. этот файл будет затем обработан в группах различий, каждая группа получает свою собственную таблицу этого месяца. у какой-то группы есть пара, у некоторых есть десятки, сотни записей. каждая запись содержит 10-20 полей. –
Структура, которую вы описываете, настолько ошибочна, чтобы быть достойной The Daily WTF (http://dailywtf.com). Возможно, вы не сможете решить проблему вздутия, не исправляя явно неправильный дизайн приложения. –
Вы можете сделать две вещи:
Связанные таблицы не будет в себя предельными общий размер базы данных, но он «упаковывает» его в более мелкие, более управляемые файлы. Для того, чтобы посмотреть в это:
'File' menu + 'Get External data' + 'Linked tables'
Связанные таблицы также имеют много преимуществ, таких как позволяя хранить несколько версий подмножества данных и выбора определенного набора путем связанного менеджера таблицы.
Компактные базы данных восстанавливают пространство, иначе теряемое, поскольку различные операции CRUD (Insert, Delete, Update ...) фрагментируют хранилище. Он также группирует таблицы и индексы, делая поиск более эффективным. Это делается с помощью
'Tools' menu + 'Database Utilities' + 'Compact and Repair Database...'
Я попытался уплотнить db, он не сделал diff :( –
@ aZn137 Отсутствие уменьшения размера после сжатия db может быть либо результатом чрезмерно фрагментированного стола (я видел это), либо обычной вещи, если CRUD операции в течение всего срока службы базы данных были таковы, что они не приводили к значительным фрагментации. Перезагрузка данных в совершенно новую базу данных (и, возможно, отдельные, связанные с сетью таблицы) может быть единственным способом «исправления» в противном случае это «несжамая» база данных. Сделайте копии оригинала, если только для защиты от опечаток и других человеческих ошибок, не говоря уже о «взрывах» MS-Access. – mjv
Вы должны действительно подумать о своей архитектуре db. Если между таблицами нет каких-либо связей, вы можете попытаться перенести некоторые из них в другую базу данных (один бит в год :) в качестве краткосрочного решения.
Вы действительно подталкиваете пределы MS Access там - знаете ли вы, что файл не может вырасти больше 2 ГБ?
Предполагаете, что вы уже изучили данные для возможной экономии пространства за счет дополнительной нормализации? Вы можете «архивировать» некоторые из таблиц за предыдущие месяцы в отдельные файлы MDB, а затем связать их (надолго или по мере необходимости) с вашей «текущей» базой данных (в этом случае вы действительно выиграете от того, что, вероятно, было в противном случае плохим решением для запуска новых таблиц за каждый месяц).
Но, с таким количеством данных, возможно, настало время приступить к планированию перехода на более емкую платформу.
+1 за хороший совет, но это понятно из описание, что схема полностью неправильно спроектирована - добавление 20 новых таблиц каждый месяц является мертвой поддачей! В то время как взлет будет избегать жесткого ограничения на 2 ГБ Jet/ACE, он не устранит основную проблему, а именно: ign просто НЕПРАВИЛЬНО. –
Добавление таблиц каждый месяц: это уже сомнительное отношение и кажется подозрительным в отношении нормализации данных.
Если вы это сделаете, я подозреваю, что ваша структура базы данных также не оптимальна в отношении размеров полей, типов данных и индексов. Я бы действительно начал с двойной проверки.
Если у вас действительно есть оправдание для ежемесячных таблиц (которые я не могу себе представить, опять же), почему бы не иметь 1 back-end в месяц?
Вы также можете иметь на основном сервере, например, через 3 месяца данных, а затем на архив db, где вы переносите старые записи.
Я использую это для транзакций, причем основной стол имеет около 650 000 записей, а Access очень отзывчив.
Если db - это тот, на который вы ссылаетесь в вопросе ссылочной целостности, я не удивлен, что у вас есть проблемы. Его дизайн - беспорядок. –
Я попытался разбить базу данных, вещь заняла почти 2 часа, а затем дала мне ошибку, «превышен максимальный счет блокировки» или какой-то убой ... –
Сообщение об ошибке, которое вы получили, должно также предоставить вам ссылку HELP, которая приведет вас к инструкциям о том, как изменить раздел реестра, который позволяет вам выполнять максимальное количество блокировок. –
Пара «Схватив за соломинку» идеи
Посмотрите на типах данных для каждого столбца, вы можете быть в состоянии хранить несколько чисел в байтах сохранения небольшого количества на каждую запись
Посмотрите на индексах и избавиться от тех, которые вы не используете. На больших таблицах ненужные индексы могут добавить большой объем накладных расходов.
I Would + 2^64 предложения о разработке базы данных был немного странным, но ничего такого, что еще не было сказано, так что я не буду останавливаться на этом
я взять его обратно, каждый месяц мы создаем ~ 20 столов , не спрашивайте меня, я не проектировал его! –
Возможно, вам стоит перепроектировать его? –
вещь беспорядок, не говоря уже о коде. есть как минимум пара тысяч строк кода, и абсолютно никаких комментариев. все это просто слишком сумасшедшее для меня, чтобы даже подумать о перепроектировании ... –