Как вставить 800000 записей в таблицу MS Access?

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

Итак, используйте этот файл, чтобы начать реальное заполнение — Access не будет запрашивать (или очень мало) дополнительного дискового пространства. Не помните, есть ли у MS Access способ автоматизировать это, но это может сильно помочь...

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

Если вы настаиваете на том, чтобы вытащить его в базу данных, то 800 000 записей за 1 минуту — это более 13 000 в секунду. Я не думаю, что вы превзойдете это в MS Access.

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

Без индексов было бы быстрее. Можно ли добавить их после импорта?

В этой теме есть ряд предложений, которые могут представлять интерес Медленная запись на диск MSAccess

Как насчет того, чтобы пропустить текстовый файл и использовать ODBC или OLEDB для импорта непосредственно из исходной таблицы? Это означало бы изменение предложения FROM для использования имени исходной таблицы и соответствующей строки соединения в качестве части IN '' предложения FROM.

РЕДАКТИРОВАТЬ: На самом деле я вижу, что вы говорите, что исходным форматом является xBase, поэтому должна быть возможность использовать xBase ISAM, который является частью Jet, вместо необходимости использования ODBC или OLEDB. Это будет выглядеть примерно так:

INSERT INTO table (...) 
SELECT * 
FROM tablename IN 'c:\somedir\'[dBase 5.0;HDR=NO;IMEX=2;];

Возможно, вам придется настроить это — я только что взял строку подключения для связанной таблицы, указывающей на файл DBF, поэтому параметры могут немного отличаться.

Как насчет альтернативной схемы...

Будет ли вариант сделать копию существующего файла базы данных Access, в котором есть эта таблица, которая вам нужна, а затем просто удалить все остальные данные, кроме этой одной большой таблицы (не знаю, есть ли в Access эквивалент чего-то вроде " обрезать таблицу» на сервере SQL)?

Я бы заменил MS Access другой базой данных, и в вашей ситуации я вижу, что Sqlite — лучший выбор, он не не требует установки на клиентскую машину, это очень быстрая база данных и одно из лучших встроенных решений для баз данных.

Вы можете использовать его в Delphi двумя способами:

1. Вы можете загрузить Dll ядра базы данных с веб-сайта Sqlite и использовать бесплатный компонент Delphi для доступа к нему, например компоненты Delphi SQLite или SQLite4Delphi

2. Используйте DISQLite3 со встроенным движком, и вы не не нужно распространять dll с вашим приложением, у них есть бесплатная версия ;-)

если вам все еще нужно использовать MS Access, попробуйте использовать TAdoCommand со статусом SQL Insert напрямую вместо использования TADOTable, это должно быть быстрее, чем использование TADOTable.Append;

Как кто-то упомянул, вы не будете импортировать 800 000 записей менее чем за минуту; это уже действительно быстро.

Однако вы можете пропустить раздражающий этап перевода в текстовый файл, если используете правильный метод (наборы записей DAO) для выполнения вставок. См. предыдущий вопрос, который я задал и ответил на StackOverflow: MS Access: почему ADODB.Recordset.BatchUpdate намного медленнее, чем Application.ImportXML?

Не используйте INSERT INTO даже с DAO; это медленно. Также не используйте ADO; это медленно. Но DAO + Delphi + Recordsets + создание экземпляра COM-объекта DbEngine напрямую (а не через объект Access.Application) даст вам большую скорость.

Вы смотрите в правильном направлении с одной стороны. Использование одного оператора для массовой вставки будет быстрее, чем попытка перебирать данные и вставлять их построчно. Доступ, являющийся базой данных на основе файлов, будет чрезвычайно медленным при итеративной записи.

Проблема в том, что Access обрабатывает внутреннюю оптимизацию записи, и на самом деле нет никакого способа контролировать это. Вероятно, вы достигли максимальной эффективности оператора INSERT. Для дополнительной скорости вам, вероятно, следует оценить, есть ли способ записи 800 000 записей в базу данных при каждом запуске приложения.

Получите SQL Server Express (бесплатно) и подключитесь к нему из доступа к внешней таблице. . SQL Express намного быстрее, чем MS Access.

Я бы предварительно заполнил базу данных и передал бы им сам файл вместо того, чтобы заполнять существующую (но пустую) базу данных.

Если данные, которые вы должны заполнить, изменились, то синхронизируйте базу данных доступа ODBC (файл MDB) на сервере, используя небольшой код, чтобы увидеть изменения в основной базе данных и скопировать их в базу данных доступа.

Когда пользователь запрашивает новую базу данных, заархивируйте MDB, передайте ее ему и откройте.

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

В качестве альтернативы, вы можете найти другой формат (кроме csv), доступ к которому может импортировать быстрее.

-Адам

Также проверьте, сколько времени потребуется для копирования файла. Это будет нижняя граница скорости записи данных. В db, подобном SQL, обычно требуется утилита массовой загрузки, чтобы приблизиться к этой скорости. Насколько мне известно, MS никогда не создавала инструмент для прямой записи в таблицы MS Access, как это делает bcp. Специализированные инструменты ETL также оптимизируют некоторые шаги, связанные со вставкой, например, то, как SSIS выполняет преобразования в памяти, DTS также имеет некоторые оптимизации.

Возможно, вы могли бы открыть набор записей ADO для таблицы с режимом блокировки adLockBatchOptimistic и CursorLocation adUseClient, записать все данные в набор записей, а затем выполнить пакетное обновление (rs.UpdateBatch).

Если он исходит из базы данных, вы можете просто скопировать файлы данных и индекса и прикрепить их напрямую без загрузки? Должно быть довольно эффективно (от людей, которые приносят вам FoxPro). Я полагаю, что он также будет использовать существующие индексы.

По крайней мере, это должен быть довольно эффективный импорт одной команды.

насколько 800 000 записей меняются от одного создания к другому? Можно ли предварительно заполнить записи, а затем просто обновить те, которые изменились во внешней базе данных при создании новой базы данных?

Это может позволить вам быстрее создать новый файл базы данных.

Как быстро вращается ваш диск? Если это 7200 об/мин, то 800 000 строк за 3 минуты по-прежнему составляют 37 строк на оборот диска. Не думаю, что у тебя получится намного лучше.

Между тем, если цель состоит в том, чтобы упростить процесс, как насчет ссылки на таблицу?

Вы говорите, что не можете получить доступ к исходной базе данных через ADO. Можете ли вы настроить ссылку таблицы в MS Access на таблицу или представление в исходной базе данных? Затем простой запрос на добавление из ссылки на таблицу скопирует данные из исходной базы данных в целевую базу данных для вас. Я не уверен, но я думаю, что это будет довольно быстро.

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

Привет. Лучший способ - массовая вставка из txt-файла, поскольку они сказали, что вы должны вставить свои записи в txt-файл, а затем массово вставить txt-файл в таблицу, время должно быть менее 3 секунд.