先确认查询要回答现在还是经过
阅读区块链分布式数据库资料时，可以先把问题拆成两类：某个对象现在是什么状态，以及它怎样变成这个状态。Fabric账本文档把世界状态与区块链列为两个相关部分。前者保存当前状态，后者记录交易历史；程序读取一个当前值时，不必每次都从最初的交易重新计算。
这种分工也说明，数据库和区块日志不能只凭文件大小或记录条数互相替代。世界状态中的键可以创建、更新和删除；区块日志则按顺序追加交易记录。本文讨论的是Fabric的账本结构，不把采用数据库复制的任何系统都称为区块链，也不把查询页面直接当成完整账本。
一个键更新三次不会留下三份当前值
用一个虚构的业务记录说明：同一通道、同一链码命名空间中，键“工单甲”先保存待处理，随后两次有效更新分别把它改成已受理和已关闭。最后查询该键的当前值，得到已关闭，属于正常结果。不能因为这次查询没有同时列出前两个值，就断定早先的交易记录被删除。
若要解释工单经过，应转向与这些更新对应的历史交易资料，并保留查询对象的通道和命名空间。Fabric文档说明，不同通道各有自己的账本，不同链码的状态也有命名空间边界。因此，另一个范围里恰好同名的键，不能不加区分地接到这条教学时间线上。
数据库修订信息不等于完整历史档案
Fabric可使用LevelDB或CouchDB实现世界状态。CouchDB自己的文档则说明，它以文档作为数据单位，并维护供更新与读取使用的版本信息。这里需要区分职责：底层数据库能够保存和更新文档，并不意味着它的每个旧修订正文都会永久保留，或者可以替代Fabric的区块日志。
Apache CouchDB的压缩说明指出，压缩会移除不用的旧数据，并将旧文档修订替换为用于复制冲突处理的少量元数据。因此，看到修订标识仍在，不能据此认定相应旧正文一定还能完整取回；数据库压缩的存储规则，也不能被解释成Fabric正在改写已经记录的业务历史。
重建能力必须对应可用的账本范围
Fabric文档说明，世界状态可以依据区块链重新生成，并描述异常重启时先恢复状态再接受交易的情形。这种可重建性来自历史记录与当前状态之间的关系，不是说任何一份孤立的当前数据库都能够反推出所有过去，也不是说缺少必要账本资料仍可凭空恢复。
整理系统说明时，可以分别记下保存的通道、状态数据库类型、可用历史范围，以及当前查询对应的处理位置。这样才能判断手头拿到的是当前状态、形成状态的交易记录，还是另外导出的报表。本例没有运行恢复或删除数据库；它只说明读资料时应先确认保存对象，再判断能够回答哪些问题。