使用MongoDB作为主数据库，是否应该使用独立图形数据库实现实体之间的关系？
我们目前正在为一家专业公司内部实施一个类似客户关系管理（CRM）的解决方案。由于存储的信息性质以及信息的不同值和键，我们决定使用文档存储数据库，因为它非常适合我们的需求（在这种情况下，我们选择了MongoDB）。
作为这个CRM解决方案的一部分，我们希望存储实体之间的关系和关联，比如存储利益冲突信息、股东、受托人等。为了有效地将这些实体联系在一起，我们认为有一个“关系”的中心模型是必要的。所有的关系都应该附带历史信息（开始和结束日期），以及不同的元数据；例如，股东关系还应该包含持有的股份数量。
由于传统的关系数据库管理系统（RDBMS）不适合我们之前的需求，因此在当前情况下使用它们并不可行。我想弄清楚的是，使用图数据库是否更适合我们的情况，还是仅仅使用MongoDB内置的关系信息就足够了。
关系信息将在系统中被频繁使用。我们希望执行的一些信息查询示例如下：
- 获取所有与“xyz有限公司”相关的公司的“关键联系人”人员
- 获取“john”作为股东的公司的所有其他“股东”信息
- 获取与“abc有限公司”相关且同时是“信任我们银行有限公司”客户的实体的所有“关键联系人”人员
考虑到这种“树状”关系结构，使用图数据库（比如Neo4j）是否更合适呢？
4 个回答
还是用MongoDB吧。两个原因：第一，如果可以的话，尽量在同一个领域里工作，这样可以减少复杂性；第二，MongoDB在查询方面表现很好，比起Redis来说，使用起来更简单，工作量也更少。
在MongoDB中，文档和Neo4j中的节点很像，只是没有关系。它们都存储键值对的属性。如果你已经决定使用MongoDB，那么可以用Neo4j来存储关系，然后在你的应用程序中把这两者连接起来。如果你在选择新技术，可以考虑全用Neo4j，因为节点同样可以存储属性数据，就像文档一样。
至于关系部分，Neo4j非常合适。它是一个图形数据库，而不是一些没有关联的文档。在这里使用图形数据库是非常合理的，示例查询中也处处体现了图形的特点。
老实说，找到适合你的最佳方法就是做一个概念验证（PoC）——成本低，价值高。
免责声明：我在Neo Technology工作。
迈克，
你应该可以把你的关系数据存储在图数据库里。图数据库在处理大图时表现得很快，这主要是因为它的局部性，也就是说，你不是在全局范围内运行查询，而是从一组节点开始（在你的情况下，这些节点相当于文档，可以通过索引查找。你甚至可以在你的Mongo文档中存储起始节点的ID，以便快速访问）。从那里开始，你可以在常量时间内遍历任意大的路径（与数据集大小无关）。
你还有哪些其他的需求呢？比如数据集的大小、同时访问的数量、关系或图的复杂性等等。
你的查询非常适合图数据库，并且可以很容易地用图数据库的方式来表达。
我建议你可以试试像neo4j这样的图数据库，快速做个小测试，看看在你的领域中是否可行，同时也可以找出在投入第二种技术之前你想要解决的其他问题。
顺便说一下，如果你还没开始的话，其实你也可以直接选择纯图数据库的方式，因为图数据库是文档数据库的一个超集。而且在你的情况下，你更应该关注领域相关的内容，而不仅仅是一些通用的文档。（例如，structr是一个基于Neo4j构建的内容管理系统）。