我最感兴趣的是针对大量变异的面向对象数据的进程内（单用户）解决方案，其中数据的任何部分都可能发生变化。此类系统通常存在以下问题：
- 从头开始写大文件效率低下
- xml 太冗长
- SQL blob 不是很好的匹配项
你是怎么做到的？
Jesse Pepper
问问题
291 次
8 回答
2
或使用几个可用的开箱即用解决方案之一进行映射。
于 2009-01-14T13:42:10.627 回答
1
这取决于您的要求。你会诚实地使用 XML 或 SQL blob 来处理高分辨率图片或音频吗？
我再次阅读您的问题：如果您有一堆任意对象要存储在文件图像中，那么将它们放入/取出的方法是复制和重定位。out-copy 可以得到 GC 的帮助。in-copy 非常简单，主要取决于重定位例程。
如果需要处理非常大的文件，我会在该系统中提供一些方法来标记对象“脏”，以及标记它们在文件图像中的实际位置。
除非您从不删除任何东西，否则还需要在已删除的对象中进行标记。
于 2009-01-14T13:35:43.823 回答
0
您可以尝试序列化为 XAML，而不是 XML。这可以创建更小的文件，并且读写速度更快（序列化/反序列化）。
显然，依赖于 XAML 是一种选择。
于 2009-01-14T13:53:50.777 回答
0
您需要 O/R 映射或像 db4o 这样的对象数据库。
如果是一组相对独立的对象的集合，也可以将每个对象存储到自己的文件中，并且只在对象脏时写入。但显然，在更复杂的情况下，保持引用的正确性和避免不直观的目录结构可能需要大量工作，而这正是 O/R 映射器和对象数据库带来的真正意义。
至于 XML 过于冗长，通常可以通过压缩来解决（例如 zip 中的 xml）。
于 2009-01-14T14:07:46.100 回答
0
我们主要使用二进制数据。除非它必须是人类可读的（如设置和用户偏好）。
如果您认为 xml 过于冗长，请查看 JSON。我认为这是一个非常好的选择。
于 2009-01-14T13:37:16.440 回答
0
对于大型数据集，我使用结构化的二进制文件，没有什么比空间和时间更有效了。
对于结构化文本数据，我将使用 s 表达式（即LAML）或减少用 i 表达式实现的括号 LAML。
于 2009-01-15T05:51:54.803 回答
0
“从头开始写大文件效率低下” 什么？很少有东西像文件 I/O 一样快。请提供一些示例或数据来支持您对文件 I/O 效率低下的断言。
大多数 OO 系统可以将对象序列化或腌制到文件中。这大约是最快的 I/O。
此外，大多数 OO 系统可以将对象转换为标准表示形式，如 XML、JSON 或 YAML。
JSON/YAML 比 XML 更简洁，更容易解析。
于 2009-01-14T13:38:25.893 回答
0
我将 YAML 用于中小型文件，非常易于解析和保存。JSON 是一个有价值的选择。
于 2009-01-14T13:44:05.617 回答