我们在开始讲解如何在 RavenDB 中建模之前，先来看看注意事项，这些内容与我们将要辨析的模型有着直接的关系。 这里需要注意的第一点是 不要在不同应用之间建立共享数据库。很多设计者会建立共享数据库，用以在不同的应用之间共享相同的数据，虽然这样做能减少数据存储量，以及实现多应用使用相同数据的目的，但是在 RavenDB 中并不推崇这样的做法。这是因为虽然不同的应用看起来有些数据是一样的，我们会强制它们使用相同的方式处理数据，但是在大多数情况下不同的应用程序使用相互不同的方式处理类似的数据，如果使用共享数据的话，一个应用程序共享数据的结构的改变就会造成其他应用跟着一起改变，进而导致数据模型复杂性增加，并且也会增加不同应用开发团队之间沟通的成本和时间。因此每个应用程序应该对立的进行数据建模，并不断的根据需求进行改进。 读到到这里，肯定有人会问了：不同的应用程序直接或多或少的都需要共享数据，那么使用 RavenDB 如何实现这一点呢？我们可以使用 RavenDB 内置的 ETL 功能在不同应用程序服务器之间建立数据/信息流（这个内容将会在后续讲解）。 另一个要注意的是 某些情况下应该数据冗余存储，比如在 Order 文档中存在 Address 文档的链接，但是如果 Address 中的配送地址变了，那么 Order 文档中的历史订单的配送地址也会跟着改变，这样就出现了我上一篇文章说的数据损坏。那么，我们在进行建模的时候，应该考虑我的关注点是当前值（例如 Order 文档中的当前订单配送地址）还是时间点值（例如 Order 文档的历史订单配送地址），如果是时间点值那么我们就需要进行数据冗余存储，例如在 Order 文档中存储配送地址的详细信息。 以上几小段的内容总结下来就是建模文档的核心原则：
- 独立，一个文档应该独立于其他任何文档而存在，如果某个文档脱离了其他文档而不具备存在的条件，那么这个文档就不是独立的，例如 Order 文档中存在 Address 文档的链接，如果 Address 文档不存在了，那么 Order 文档也就不存在了。
- 隔离，文档的更改不会影响到其他文档，文档应该能独立于其他文档进行修改，当每个文档都具有了隔离性，事务的边界就更加清晰了。
- 连贯一致性，文档本身应该清晰可读，不需要去链接其他文档进行理解。文档应该向一个说明书一样，我们只需要查看这个说明书就能理解产品的操作，而不必在看说明书的同时再去翻阅其他资料文档。
