图形或关系数据库专门递归答案

【问题标题】：Graph or Relational DB specifically recursion图形或关系数据库专门递归
【发布时间】：2013-12-13 20:57:12
【问题描述】：

我即将为客户开发一个解决方案，其中基本实体是成员，成员可以与其他成员有不同的多重社会关系。例如，假设我们有四种类型的成员医生、专家、护士和患者。因此，一位或多位医生可以咨询一位或多位专家，一位或多位医生可以治疗一位或多位患者。一名或多名医生负责一名或多名护士。因此，如果我要使用关系数据库，则需要高度递归（因为所有实体都必须是成员）。而在 Graph 数据模型中不需要递归。

是否可以肯定地说，将图形数据库用于社交类型的应用程序更好，其中成员可能具有不同或重叠的角色。

【问题讨论】：

我认为不需要递归。递归将是医生咨询医生。
医生、专家、护士和患者都是会员，医生也可以是患者并咨询其他医生，以及一名或多名医生负责一名或多名医生。
用尖尖的棍子给自己挖一个大洞，然后从 500 英尺高的地方跳进去，带着 500 磅。就与医生的关系而言，耐心的医生不是医生。
我同意，但是他们作为医生的角色确实存在，因为它是不可忽视的成员。
只是因为您指定的是成员之间的关系而不是医生和患者之间的关系。听医生的话，预防胜于治疗。 :)

标签： recursion neo4j relational-database graph-databases

【解决方案1】：

图形数据库擅长对这些类型的关系进行建模。您可以通过几种方式对其进行建模。您可以将顶点视为一个成员，从成员到其他成员的不同边代表关系类型：

会员 --consults--> 会员（医师到专家）
会员 --reportsTo--> 会员（护士到医生）
成员 --diagnoses--> 成员（医生到患者）

显然，一个会员可能拥有任意数量的边缘类型（例如多次“咨询”专家）。在更复杂的模型中，您可能还会将成员视为一个人的“身份”，这样您的模型看起来像：

成员 --actsAsPhysician--> 医师
成员 --actsAsSpecialist--> 专家
医师 --consults--> 专家

在这种方法中，“consults”边只能存在于“Physician”顶点上，因此您可以对哪些顶点类型可以预期具有哪些边提供一些约束。

图表为您提供了很大的灵活性，让您能够对现实世界中存在的数据进行建模，因为您实际上只是在描述实体及其之间的关系。我鼓励您查看 http://tinkerpop.com 以获取有助于构建独立于您选择的图形数据库的图形应用程序的工具集。

【讨论】：

【解决方案2】：

如果每个人都是成员，那么从关系的角度来看，成员是数据模型的核心。不需要递归 SQL 选择语句：

会员 ->------

您的模型将有很多多对多关系和很多关系表。例如，Treats 关系可以包含诸如 Treatment Period 之类的属性病痛等等

您的解决方案可以在任何拓扑中实施。虽然网络/图拓扑比 Set 拓扑更快，但图数据模型一旦实现几乎不可能更改。历史告诉我们，构建死板的业务应用程序是不明智的。因此，请研究每种方法的优缺点并做出决定。

【讨论】：