棘手的问题 - 但我会分享我的经验,让你决定它是否有帮助。
如果您需要保留处理源文件的输出,并使用它来生成派生数据的多个视图,那么您可以考虑使用嵌入式数据库。使用嵌入式数据库(恕我直言)的原因:
- 利用 RDBMS 功能(ACID、关系、外键、约束、触发器、聚合......)
- 为了更容易以灵活的方式导出数据
- 允许外部客户端访问您处理的数据(已知格式)
- 在准备查看时允许更灵活地转换数据
做出决定时应考虑的因素:
- 目标平台是什么(windows、linux、android、iPhone、PDA)?
- 有什么技术基础?(Java、.Net、C、C++、...)
- 预期或需要针对哪些资源限制进行设计?(RAM、CPU、硬盘空间)
- 您需要考虑哪些操作行为(连接到网络、断开连接)?
在典型的现代桌面上,有足够的备用容量来处理大多数操作。在 eeePC、PDA 和其他便携式设备上,可能不是。在嵌入式设备上,很可能不会。您使用的语言可能具有帮助内存管理的内置功能 - 也许您可以利用这些功能。连接方面(有状态/无状态/等)可能会影响您在任何给定点真正需要保留多少内存。
如果您正在处理非常大的文件,那么您可能会考虑使用流式处理方法,这样您一次只能在内存中保存一小部分整体数据 - 但这并不意味着您应该(或不应该)使用嵌入式数据库。纯文本或二进制文件也可以正常工作(基于记录、基于列、基于行……等等)。
某些数据库将允许您在数据存储后以更有效的方式与数据进行交互——这取决于引擎。我发现如果您的基本文件(我的意思是您最初从原始源生成的文件)中需要大量聚合,那么 RDBMS 引擎对于简化逻辑非常有帮助。其他选项包括构建您的基本转换,然后添加额外的步骤以将其处理到每个特定视图的其他临时存储中,然后依次处理这些转换以呈现为目标(报告?)格式。
只是一种意识流反应——希望能有所帮助。
编辑:
根据您的进一步说明,我不确定嵌入式数据库是您想要采取的方向。您要么需要为渲染图形做出某种简化假设,要么研究分段等方法(渲染图形的各个部分,然后在渲染下一部分之前缓存输出)。