Максимальное количество строк в таблице MS Access database engine?

мы знаем, что MS Access database engine "дросселирован", чтобы позволить максимальный размер файла 2 ГБ (или, возможно, внутренне проводной, чтобы быть ограниченным менее чем некоторой мощностью 2 из 4KB страниц данных). Но что это означает на практике?

чтобы помочь мне измерить это, можете ли вы сказать мне максимальное количество строк, которые могут быть вставлены в таблицу MS Access database engine?

чтобы удовлетворить определению таблицы, все строки должны быть уникальными, поэтому уникальное ограничение (например,PRIMARY KEY, UNIQUE, CHECK, макрос данных и т. д.) является требованием.

EDIT: я понимаю, что есть теоретический предел, но то, что меня интересует, является практическим (и не обязательно сроки), предел реальной жизни.

8 ответов


некоторые комментарии:

  1. Jet/ACE файлы организованы в страницах данных, что означает, что есть определенное количество свободного места, когда ваши границы записи не выровнены со страницами данных.

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

  3. в Jet 4 Размер страницы данных был увеличен до 4KBs (с 2KBs в Jet 3.икс.) Как Jet 4 был первым Jet версия для поддержки Unicode это означало, что вы можете хранить 1 ГБ двухбайтовых данных (т. е. 1,000,000,000 двухбайтовых символов), а при включенном сжатии Unicode-2 Гб данных. Таким образом, количество записей будет зависеть от того, включено ли сжатие Unicode.

  4. поскольку мы не знаем, сколько места в файле Jet/ACE занимают заголовки и другие метаданные, а также сколько места занимает хранилище индекса, теоретический расчет всегда будем под тем, что практично.

  5. чтобы получить максимально эффективное хранилище, вы хотите использовать код для создания базы данных, а не пользовательский интерфейс доступа, потому что Access создает определенные свойства, которые не нужны pure Jet. Это не значит, что их много, так как свойства, установленные по умолчанию для доступа, обычно не устанавливаются вообще (свойство создается только при изменении его значения по умолчанию - это можно увидеть, проехав по полю коллекция свойств, т. е. многие свойства, перечисленные для поля в конструкторе таблиц доступа, отсутствуют в коллекции свойств, поскольку они не были установлены), но вы можете ограничить себя типами данных, специфичными для Jet (например, поля гиперссылки-только для доступа).

Я просто потратил час, возясь с этим, используя Rnd() для заполнения 4 полей, определенных как тип byte, с составным PK на четырех полях, и потребовалась вечность, чтобы добавить достаточно записей, чтобы получить до любой значительной части 2GBs. На более чем 2 миллиона записей, файл был под 80MBs. Я, наконец, бросить после достижения просто 700K 7 млн. записи и файл уплотнены до 184MBs. Количество времени, которое потребуется, чтобы встать рядом с 2GBs просто больше, чем я готов инвестировать!


вот моя попытка:

Я создал один столбец (INTEGER) таблица без ключа:

CREATE TABLE a (a INTEGER NOT NULL);

вставленные целые числа в последовательности, начинающейся с 1.

Я остановил его (произвольно после многих часов), когда он вставил 65,632,875 строк. Размер файла составил 1,029,772 КБ.

Я сжал файл, который уменьшил его очень немного до 1,029,704 КБ.

я добавил в PK:

ALTER TABLE a ADD CONSTRAINT p PRIMARY KEY (a);

что увеличило размер файла до 1,467,708 КБ.

это предполагает, что максимум где-то около 80 миллионов марок.


Как заявили другие, это комбинация вашей схемы и количества индексов.

у друга было около 100,000,000 исторических цен на акции, ежедневные котировки закрытия, в MDB, который приблизился к пределу 2 Гб.

Он вытащил их, используя некоторый код, найденный в статье базы знаний Microsoft. Я был довольно удивлен, что какой бы сервер он ни использовал, он не отключил его после первых 100k записей.

Он мог просмотреть любую запись в второй.


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

Если файл базы данных не доступен только одному человеку или хранится в надежной сети, вы можете обнаружить, что это проблема до достижения предела размера базы данных 2GB.


мы не обязательно говорим о теоретических ограничениях здесь, мы говорим о реальных ограничениях максимального размера файла 2GB и схемы базы данных.

  • является ли ваш db одной таблицей или несколько?
  • сколько столбцов имеет каждая таблица?
  • какие типы данных?

схема находится на четной основе с количеством строк в определении того, сколько строк вы можете иметь.

мы воспользовались Доступ к MDBs для хранения экспорта данных MS-SQL для статистического анализа некоторыми нашими корпоративными пользователями. В этих случаях мы экспортировали нашу основную структуру таблиц, обычно четыре таблицы с 20 до 150 столбцами, варьирующимися от ста байтов в строке до более 8000 байтов в строке. В этих случаях мы сталкивались с несколькими сотнями тысяч строк данных, допустимых для MDB, которые мы отправляли.

Итак, я просто не думаю, что этот вопрос имеет ответ в отсутствие вашего схема.


все зависит от того. Теоретически, используя один столбец с типом данных 4 байта. Можно хранить 300 000 строк. Но, вероятно, есть много накладных расходов в базе данных еще до того, как вы что-либо сделаете. Я читал некоторые, где вы могли бы иметь 1.000.000 строк, но опять же, все зависит..

вы также можете связать базы данных вместе. Ограничьте себя только дисковым пространством.


Practical = 'полезно на практике' - так что лучшее, что вы собираетесь получить, это анекдотический. Все остальное-просто прототипы и результаты тестирования.

Я согласен с другим - при определении максимального количества записей полностью зависит от схемы - таблицы # поля # индексы#.

еще один анекдот для вас: недавно я ударил размер файла 1.6 GB с 2 первичными хранилищами данных (таблицами), 36 и 85 полей соответственно, с некоторыми копиями подмножеств в 3 дополнительных таблицах.

кого волнует, уникальны данные или нет-только материал, если контекст говорит об этом. Данные-это данные, если дублирование не влияет на обработку индексатором.

общее количество строк, составляющих 1,6 Гб, составляет 1,72 м.


при работе с 4 большими таблицами Db2 я не только нашел предел, но это заставило меня выглядеть очень плохо для босса, который думал, что я могу добавить все четыре таблицы (каждая с более чем 900 000 строк) к одной большой таблице. реальный результат жизни заключался в том, что независимо от того, сколько раз я пробовал таблицу (которая имела ровно 34 столбца - 30 текстовых и 3 целых), выплюнет какое-то загадочное сообщение "не удается открыть базу данных непризнанного формата или файл может быть поврежден". Итог меньше, чем 1,500,000 записи и чуть больше, чем 1,252,000 с 34 строками.