RavenDB 文档建模 -- 开篇

数据建模直接影响到数据库完成工作的效率，我们。常见的建模时基于关系数据的建模，这种建模被称为数据建模，有点如下：

它建立在严格的数学概念之上，具有坚实的理论基础；
无论是实体还是实体之间的联系都用关系来表示，对数据的检索结果也是关系；
存取路径对用户透明，具有更高的数据独立性，更好的安全保密性，也简化了程序员的工作和数据库开发建立的工作。
但是如果我们尝试将关系建模方案应用于非关系行数据库时，终的结果往往时令人尴尬的。这是因为非关系型数据库是 Documents aren’t flat （我称之为立体文档） ，它和关系型数据库里的每一行只能存储简单的值是不同的，非关系型数据库里面往往存储的不仅仅是键和值，很多时候它里面存储的是数组、字典以及树等这种复杂类型的数据结构。非关系型数据库的巨大优势就在这里，它简化了很多常见的场景数据存储。
关系型数据库有一套标准化的内容（比如说数据完整性），标准化有助于减少数据重复，常见的情况是在线商城中的订单模块，配送地址的 ID 作为外键存储在订单表中，这样使得我们不用在多个订单中修改配送地址。但是这里存在一个致命的问题，历史订单已经完成了配送，当我们修改的地址与历史订单有关联时就会出现历史订单的配送信息改变了，这样就造成了数据损坏。这个问题是在建模过程中出现的缺陷（解决这个问题也很简单，在这里我们就不再讨论），这是建模人员只局限于以关系的眼光看待事务造成的。
在 RavenDB 这种非关系型文档数据库中并不能完全解决这个问题，但是对于大多数业务系统来说 RavenDB 存储数据的模型还是比较合适的。在 RavenDB 中每个文档都是一个聚合，它是面向文档的建模技术，为解决类似于订单和地址这种问题提供了很好的解决方案。

Q：什么是聚合？
A：聚合可以被看做单个单元的域对象集群，订单和订单的内容就是聚合。

在这个专题中，我们将学习如何拜托关系型思维模式以及如何为 RavenDB 建模。
————————————————
版权声明：本文为CSDN博主「喵叔哟」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/gangzhucoll/article/details/123436315