Плоский файл в делфи

Если вы не хотите изобретать велосипед, вы можете найти все необходимые Open Source инструменты для вашей задачи у нас:

• Synopse Big Table для хранения огромного количества данных — см. в частности, класс TSynBigTableRecord для хранения неограниченного количества записей с полями, включая индексы, если это необходимо - он определенно будет быстрее и будет использовать меньший размер диска, чем любая другая обычная база данных SQL.
• Synopse SQLite3 Framework, если вы предпочитаете использовать стандартный механизм SQLite. для хранилища - поставляется с полным ORM клиент/сервер
• Отчетность из кода, включая файл PDF поколение

С полным исходным кодом, работающим от Delphi 6 до XE.

Я только что обновил документацию фреймворка. Более 600 страниц с подробным описанием каждого метода класса и новым расширенным общим введением. См. документ SAD.

Обновление. Если вы планируете использовать SQLite, вам следует сначала угадать, как будут храниться данные, какие индексы должны быть созданы и как SQL-запрос может ускорить ваши запросы. Плохая идея читать все содержимое файла для каждого запроса: вам следует лучше структурировать свои данные, чтобы один SQL-запрос мог вернуть затраченные результаты. Иногда хорошей идеей является использование дополнительных значений (например, временных сумм или средних значений) к данным. Также рассмотрите возможность использования виртуальной таблицы RTree SQLite3, предназначенной для ускорения доступ к double мин./макс. многомерным данным: это может намного ускорить ваши запросы.

Вы не хотите использовать полную базу данных SQL и считаете простой текстовый файл слишком простым.

Пункты между ними включают:

1. Что-то, что не является полной базой данных SQL, а больше похоже на хранилище ключей и значений, технически не будет плоским файлом, но оно предоставляет единый список «ключ + значение», который можно быстро найти по одному первичному ключу. Например, БСДБ. В названии есть буквы Д и Б. По вашему мнению, это делает его базой данных? Потому что это не реляционная база данных и не работает с SQL. Это всего лишь двоичный механизм хранения BLOB-объектов типа "ключ-значение" (хэш-таблица), использующий хорошо понятный формат двоичных файлов. Лично я бы не стал начинать новый проект и использовать что-либо из этой категории.

2. Рекомендуется: что-то, что использует SQL, но не такое большое, как автономные серверы баз данных SQL. Например, вы можете использовать SQLite и оболочку Delphi. Он хорошо протестирован и используется во многих приложениях C/C++ и Delphi, и ему можно доверять больше, чем всему, что вы могли бы создать самостоятельно. Это очень легкая встроенная база данных, и многие ей доверяют.

3. Создайте свой собственный ISAM или VLIR, который со временем превратится в вашу собственную СУБД. Здесь задействовано несколько файлов и есть индексы, поэтому вы можете быстро искать данные, не загружая все в память. Не рекомендуется.

4. Самый плоский из плоских двоичных файлов с фиксированной длиной записи. Первоначально вы упомянули в своем вопросе, power basic, в котором есть что-то, называемое файлами произвольного доступа, а затем вы удалили это из своего вопроса. Вероятно, это то, что вы ищете, особенно запись только для добавления в качестве основной операции. Сверните свою собственную эру TurboPascal "файл записи". Если вы используете тип «ФАЙЛ ЗАПИСИ», вы достигаете предела в 2 ГБ и возникают проблемы с Unicode. Вместо этого используйте TStream, например это. Форматы двоичных файлов имеют много недостатков, особенно потому, что со временем трудно увеличивать и расширять формат двоичных файлов, не нарушая вашу способность читать старые файлы. Это ключевая причина, по которой я бы рекомендовал вам начать с того, что на первый взгляд может показаться излишним (SQLite), вместо того, чтобы создавать собственное бинарное решение.

   (Обновление 2: после обновления вопроса с упоминанием PDF-файлов и тем, что звучит как требование к системе отчетности, я думаю, что вам действительно следует использовать настоящую базу данных, но, возможно, небольшую и простой в использовании, например, firebird или interbase.)

Я бы предложил использовать TClientDataSet и использовать его методы SaveToFile()/SaveToStream() с помощью генерирующей программы и LoadFromFile()/LoadFromStream() методы для программы, которая будет "потреблять" данные. Таким образом, вы по-прежнему можете делать проиндексированные записи без подключения к какой-либо внешней базе данных, сохраняя при этом данные обмена в одном файле.

1. Определите API для работы с вашим плоским файлом, чтобы API можно было реализовать с помощью отдельного уровня данных разными способами.
2. Реализуйте API, используя стандартную встроенную базу данных SQL (например, SQLite или Firebird).
3. Только если со стандартным решением что-то не так, придумайте свое.

Я использую KBMMemtable — см. http://www.components4developers.com/ — быстрый, надежный, долгое время - поддерживает потоковую передачу двоичных файлов и CSV в файлы и из них, а также индексирование, фильтры и множество других полезных функций - TClientDataSet не будет хорошо работать с большими наборами данных.