创建一个360°视图 第二部分：模式开发

本文译自Eric Holzhaue的英文博客：http://www.mongodb.com/blog/post/creating-single-view-part-2-schema-development。

在本系列关于360°视图的第一部分中，我们讨论了如何修改数据的思维模型以便于在MongoDB中创建一个360°视图。我们的示例场景是一家同时在互联网和实体店中销售产品的零售商。先回顾一下，以前的数据模型也许是这样的：

传统思维模型

我们推荐的新模型是这样的：

MongoDB思维模型

记住这些，我们将讨论实现这个新模型的一些细节。

360°视图模式

在本系列的第一篇博客中，我们提出了一些关于如何使用360°视图需要回答的问题，然后我们基于这些问题设计了一个数据模型。在我们的示例中，用户和产品模型也许会是这样的：

文档结构

非常直接明了的文档结构，这里有一些建议：

• 使用数组存储多重关系：单个用户有多个位置，并且有可能附属于多个组织。
• 使用有意义的、灵活的方式存储数据。在这里，我们不使用一个“家庭住址”的字段和一个“工作地址”的字段，而是使用一个单一字段用于存储所有相关地址的数组。
• 可使用标签描述一个用户。例如，你可以使用“前10%”或者“存在潜逃风险”来标记一个顾客，从而基于这些标签采取行动。
• 行为数组是一个泛型容器，它允许配置文件管理相关对象并且在合适的上下文环境中使用。这意味着什么？例如，它可以存储销售或服务代表在他们的交互中最需要的信息。
• 在用户文档中，我们在产品数组内存储购买及交互细节。
• 但是，我们也可以链出到产品文档以获得所有的产品细节。
• 相同地，产品文档也也可以存储评论，然后将其链出到进行评论的顾客。

在JSON中，文档结构是什么样的呢？下面是一个用户文档的案例。

你可以很容易清晰地看出文档的主要部分：用户元数据、行为以及产品（就像图表中列出的）。

好的，你已经构建了一个工作原型。但是，还记得我们在第一部分中提到的构建原型然后快速迭代吗？假设你想向第一个版本添加情感分析。没问题，通过使用动态模式，改进你的数据模型将变得非常容易。下面是你可以采用集成一些情感分析的第一个版本：

文档结构+情感

在这个图中，我们已经向用户文档中添加了两个字段：一个用于个人情感（用户一般的情感倾向）、一个用于对于你公司的特定情感。在产品文档中，我们使用一个数组来存储关于特定交互的更多细节。

再一次，使用JSON。下面是新的用户文档。

正如你看到的，第一步实现非常简单。我们在一个较高的层次总结了情感：客户要么是友好的（1）、中性的（0）或者是不友好的（-1），要么喜欢我们（1）、没有意见（0）或者是及其讨厌我们（-1）。同样地，随着向情感分析模块添加更多细节以及评分规则，你可以容易地改进MongoDB中的存储方式。

总结一下

接下来我们回到第一部分中的一些问题。当然，你设计模式的特定方法依赖于你的数据。但是，你应该经常回顾那些引导性的问题，从而设计出能够对你自己的用户案例有意义的东西。如果你已经阅读完上面所有内容并且开始产生疑惑，或者如果你只是跳读到这里来看总结，你应该记好这两个设计360°视图的原则：

• 你360°视图的中心是什么？是用户？还是产品？或者，和我们示例中一样，两个都是——伴随着合适的链接及嵌入。
• 针对你的数据，你提出了什么问题？访问模式应该驱动数据模型。一旦你在MongoDB上构建了你的360°视图，你如今不能回答的问题将会变成你的查询，你的数据模型也应该为它们进行优化。

当然，这里还有另外一个大问题并没有在前两个部分得到解决：数据目前存放在各个地方，你如何真正地把它导入MongoDB？继续阅读即将到来的第三部分，寻找这个问题的一些答案。

在等待的同时，你可以下载白皮书以了解更多关于MetLife如何使用MongoDB构建一个360°顾客视图的案例

关于原文作者-Eric

Eric Holzhauer是MongoDB的一位产品市场经理。