Формат файла произвольного доступа для иерархически организованных двоичных и текстовых файлов
Настольное приложение Windows, в состав которого я работаю, использует устаревший MFC CArchive в качестве формата файлов приложения для сериализации как текстовых, так и двоичных файлов на диск и с него. Приложение используется для локализации строк, содержащихся в этих текстовых / двоичных файлах, а CArchive инкапсулирует «проект» перевода, поэтому он генерируется как один монолитный файл, содержащий один или несколько из этих вложенных файлов.
Этот формат файла во многом отражает его возраст, и мы надеемся изменить его на что-то более современное. Наша главная проблема в том, что он медленный и занимает много памяти; это не произвольный доступ, поэтому доступ к произвольному файлу в архиве или даже просто создание списка каталогов требует загрузки всего объекта в память, поэтому использование пространства и времени при манипулировании архивом зависит от его размера, и это невозможно сделать на месте обновления архива тоже нет.
Наконец, расширение формата является болезненным, так как оно включает в себя засорение нашего кода условными операторами, которые сериализуют определенные поля (или нет) в архив или из архива в зависимости от значения штампа версии архива.
Я провел некоторое время, рассматривая альтернативы, среди которых выделяются ZIP / 7Z или SQLite, поскольку в ZIP уже встроена большая часть встроенных функций управления файлами / индексации, а SQLite идеально подходит для хранения и поиска. и поиск строк, так что я думаю, что комбинация этих двух технологий могла бы быть подходящим способом.
Насколько я понимаю, хитрость заключалась в том, чтобы организовать или разбить базу данных SQLite таким образом, чтобы по мере ее роста она не замедлялась, а поиск можно было ограничить отдельными файлами, создавая одну таблицу на файл или одну БД. за файл я не уверен.
Кто-нибудь еще пробовал такую вещь, и если да, то какой-нибудь совет?
Спасибо
Решение
В качестве файловой базы данных SQLite может использоваться для реализовать формат файла приложения.
Если все, что вам нужно, это хранить встроенные файлы, вы можете поместить в таблицу кучу блобов (см. sqlar для примера). Но если вы хотите смоделировать внутреннюю структуру этих файлов, вы, конечно, можете иметь более сложные таблицы.
Чтобы ограничить поиск по файлам, вам просто нужно сохранить что-то для идентификации файла:
CREATE TABLE Strings (
StringID INTEGER PRIMARY KEY,
FileID REFERENCES FileTable(FileID),
Value TEXT,
[...]
);
так что вы можете ограничить свои запросы:
SELECT * FROM Strings WHERE Value = 'hello' AND FileID = 42;
Если вы не хотите искать целые строки, но слова внутри них, рассмотрите возможность использования расширение полнотекстового поиска.
Другие решения
Других решений пока нет …
detector