Плоский файл в Delphi

Question

В моем приложении я хочу использовать файлы для хранения данных. Я не хочу использовать базу данных или открытый текстовый файл, цель состоит в том, чтобы сохранить двойные и целочисленные значения вместе со строкой просто для идентификации имени записи; Мне просто нужно сохранить данные на диске для генерации отчетов. Файл может расти даже до гигабайта. Какой формат вы предлагаете использовать? Binary? Если да, какой компонент / библиотеку vcl вы знаете, какой из них лучше использовать? Моя цель состоит в том, чтобы создать приложение, которое создает и обновляет файлы, в то время как другой инструмент «съест» эти файлы. создание хороших отчетов в формате PDF для пользователя по запросу. Как вы думаете? Любая идея или предложение?

Заранее спасибо.

Answer 1

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

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

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

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

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

Answer 2

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

Точки между ними включают:

1. То, что не является полной базой данных SQL, а скорее хранилищем значений ключей, технически не будет плоским файлом, но оно предоставляет единый список «ключ + значение», который можно быстро найти на один первичный ключ. Такие как BSDDB. Он имеет букву D и B в названии. Это, на ваш взгляд, делает его базой данных? Потому что это не реляционная база данных, и не делает SQL. Это просто механизм хранения двоичных двоичных ключей (хеш-таблиц), использующий хорошо понятный двоичный формат файла. Лично я не стал бы начинать новый проект и ничего не использовать в этой категории.

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

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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