RavenDB 文档建模--RavenDB 高级建模方案

上篇文章讲解了标准业务数据的建模方案，但是在实际项目中还存在非标准方案来解决大量复杂的数据结构，那么本篇文章就来讲讲。

Reference data

Reference data 在项目中很常见，比如省市列表、税率列表等，这些都可以作为 Reference data 存储在库中。它的特点就是小（占用空间小，变动小），而且独立存在（它的改变不会几乎很少影响到其他文档）。比如以省市列表为例，我们可以为每个省市信息定义一个文档，Id 就是省市简称，Name 值为省市全名，这种方式看起来很好，但是并不是最好的办法。根据建模基本原则这样设计出来的文档不符合独立性和连贯性，这样做也没有任何意义（如果把全国34个省级区域写入库中就需要有34个文档）。我们可以将所有的省市列表以 K/V 的形式放入一个文档中，如下代码：

{  
  "BJ":"北京",  
  "HN":"河南",  
  "HAN":"海南",  
  "HUN":"湖南",  
  "SH":"上海"  
}

上面这种对 Reference data 建模的方式有如下几个有点：

• 数据易于处理，可以一次性将所有内容加载出来，减少 RavenDB 的处理次数；
• 融入了 RavenDB 缓存数据的方式；
• 降低了反序列化的成本；
• 降低了使用和编辑数据的成本。

TIP：Reference data 会使一个单一的文档，因此我们可以使用 RavenDB 做更多的任务，这些将在后续内容中讲解。

层次结构

当数据分层越多，其复杂程度约高，这时在某些情况下，如果我们遍历层次结构的话，会出现大量的性能开销。我们来看一下常见的层次结构的类型：

• 简单层次结构：这种结构可以轻而易举的放在单个文档中，比如一篇文章所对应的评论，这些评论我们可以放在这篇文章的文档中，便利一篇文章评论的开销是非常小的；
• 分离层次结构：这种结构有多少层级我们并不清楚，而且在最底层还存其他数据，因此它就不适合放在单个文档中，比如公司组织架构，最底层是每个员工的信息，我们将这些信息全部放在一个公司文档里的话文档会十分庞大，并且还不利于操作查询。这时我们就需要将员工信息和每个层级的部门信息从公司文档里单拎出作为独立的文档，并定义好上下级关系以及员工与部门的关系即可。分离层次结构给我们带来了很多的便利性，比如分层操作、查询，而且分离层次结构可以很好的与缓存和异步加载相结合使用。这种方式如果进行单级别查询的话是很方便的，但是如果要查询某个级别下的所有级别的话就需要使用到索引，索引相关的内容我将在后面的专题文章种讲解。

时态数据模型

时态数据是一个高难的挑战，它只是存储与时间相关的数据的一种方式，比如你每月的花费、每月的工资条、加班情况等等。随着时间的推移，你每个月的花费肯定都不一样，工资也会上涨，加班情况也会变化。在 RavenDB 中对时态数据进行建模的方法是 ​完全接受其文档性质​ ，因为在大多数时态域中，文档和视图随时间变化的概念非常重要。例如，本月1号工资单发了现时，给出了追溯加薪，那么这笔钱是如何计算的？以这个为例，我来讲解一下，当将数据建模为物理文档时，我们不需要将工资存根建模为可变实体，而是将时间点视图建模。在其涵盖的时间范围内所做的任何更改都将反映下一个月的工资单中。这种方法不必同时跟踪有效时间和双时空时间，只存储加薪事实和加薪时间就行。