一个 Windows 桌面应用程序,我所在的开发团队使用遗留的 MFC CArchive 作为其应用程序文件格式,以将文本文件和二进制文件序列化到磁盘或从磁盘序列化。该应用程序用于本地化这些文本/二进制文件中包含的字符串,而 CArchive 封装了一个翻译“项目”,因此它生成为一个包含一个或多个这些子文件的整体文件。
这种文件格式在很多方面都显得过时了,我们正在寻求改变为更现代的格式。我们主要担心的是它速度慢并且占用大量内存;它不是随机访问,因此访问存档中的任意文件甚至只是生成目录列表都需要将整个文件加载到内存中,因此操作存档的空间和时间消耗取决于它的大小,而且这样做是不可行的存档的就地更新。
最后,扩展格式是痛苦的,因为它涉及到我们用条件语句乱丢我们的代码,这些条件语句根据存档的版本标记的值将某些字段(或不)序列化到存档或从存档中序列化。
我花了一些时间研究替代品,最突出的是 ZIP/7Z 或 SQLite,因为 ZIP 已经内置了大部分文件管理/索引功能,而 SQLite 是理想的字符串的存储、检索和搜索,所以我认为这两种技术的某种组合可能是可行的方法。
据我所知,诀窍是组织或分区 SQLite 数据库,使其在增长时不会变慢,并且可以通过为每个文件创建一个表来将搜索限制在单个文件中还是每个文件一个数据库,我不确定。
有没有其他人尝试过这样的事情,如果有,有什么建议吗?
谢谢
最佳答案
作为基于文件的数据库,SQLite 可用于 implement an application file format .
如果您只想存储嵌入式文件,您可以将一堆 blob 放入表中(参见 sqlar 的示例)。但是,如果您想对这些文件的内部结构进行建模,您当然可以使用更复杂的表。
要限制对文件的搜索,您只需要存储一些东西来识别文件:
CREATE TABLE Strings (
StringID INTEGER PRIMARY KEY,
FileID REFERENCES FileTable(FileID),
Value TEXT,
[...]
);
这样您就可以限制您的查询:
SELECT * FROM Strings WHERE Value = 'hello' AND FileID = 42;
如果您不想搜索整个字符串而是搜索其中的单词,请考虑使用 full-text search extension .
关于c++ - 分层组织的二进制和文本文件的随机访问文件格式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/43048848/