mysql - neo4j 示例 - 图与关系概念

Question

在我接触过关系型 mySQL 之前，我并不认为自己也是该领域的专家。我发现了以下问题 1 2关于数据库设计，但我想知道您对我的问题的看法。我想创建我自己的样本数据集，我可以在上面测试我的 Cypher 查询。我想到的一个领域是类似于面向音乐听众的社交网络的数据集，例如 LastFM。

所以我的第一个想法是创建两种类型的节点 Bands 和 Persons:

(nir:Band   { name: "Nirvana", town: "Seatle", country: "USA",  genere: "Grunge" })
(dgr:Person { name: "Dave Grohl", born: 1969, instrument: "drums" })

作为一个人，我还为我的社交网络创建了用户(不是乐队成员)。我有以下几种关系:

(dgr)-[:IS_MEMBER_OF {from: 1987, to: 1994} ]->(nir)
(user1)-[:IS_FRIEND_OF]->(user6)
(user1)-[:LIKES]->(nir)

然后我意识到这个概念至少有三个限制，我现在可以看到:

1. 乐队只能按一种流派分类
2. 乐队只能来自一个城镇/国家
3. 乐队成员只能在他曾经所属的所有乐队中演奏一种乐器

为了解决前两个问题，我首先想到了一些类似于数组的数据类型(从 Python 等中得知)。在这个数组中可以存储多个元素(多个流派或多个城镇和国家)，但我没有在 neo4j 中找到任何关于数组的信息。然后我意识到所有这些限制都可以被 neo4j 优雅地自然地解决，唯一需要做的就是对节点和关系进行轻微的修改:

(nir:Band   { name: "Nirvana" })
(foo:Band   { name: "Foo Fighters" })

(dgr:Person { name: "Dave Grohl", born: 1969 })

(grn:Genere { name: "Grunge" })
(rck:Genere { name: "Rock" })

(dgr)-[:IS_MEMBER_OF {from: 1987, to: 1994, instrument:"drums"} ]->(nir)
(dgr)-[:IS_MEMBER_OF {from: 1994, to: 1998, instrument:"drums"} ]->(foo)
(dgr)-[:IS_MEMBER_OF {from: 1998, to: 2014, instrument:"guitar"} ]->(foo)

(stl:Town    { name: "Seatle" })
(por:Town    { name: "Portland" })

(usa:Country { name: "USA" })

(stl)->[:IS_IN]->(usa)
(por)->[:IS_IN]->(usa)

(nir)->[:IS_FROM]->(stl)
(nir)->[:IS_FROM]->(por)

(nir)->[:PLAYS]->(grn)
(nir)->[:PLAYS]->(rck)

(user1)-[:IS_FRIEND_OF]->(user6)
(user1)-[:LIKES]->(nir)

最后是我的问题:

1. 可以说我对上述限制很满意并且它完全符合我的需要(乐队只能来自一个城镇等)。还是最好有不同类型的节点(城镇、国家、流派)提及？与创建完全不同的节点类型相比，在现有节点中使用属性是否有任何(性能)​​优势，将是与具有代表例如的类型节点相关仪器或与 future 观点完全不同的东西？
2. 关系数据库中有一个规则，当你有 m:n您将需要连接表的关系。这也可以应用于图形数据库而不是连接表创建新节点类型是必需的(城镇、国家、类型)？

编辑回复@Michael Hunger

“你应该问问自己，你想用它解决哪些查询/用例”如果 instrument 是 IS_MEMBER_OF 关系的成员，或者如果 instrument 是 Person 的成员，我仍然可以(也许 Cypher 查询会看起来更笨拙，我不知道)以获得所需的数据，例如向我展示在来自美国的乐队中演奏的所有鼓手。当然，我受到上述限制的限制(人只能在一种乐器上演奏等)。我的问题是，如果我知道这些限制(第一个提议的模式)并且我对它们感到满意，那么创建另一个(第二个提议的模式)数据库模型是否有意义。与第一个方案相比，第二个方案有什么好处吗？我现在可以看到的是，与第一个模式相比，第二个模式扩展得很好，还有其他东西吗，例如性能？

“对于某些特定的用例，将乐队成员建模为节点可能会很有趣，然后您可以将它们连接到乐器节点、时间树(年->月->成员)或将它们放入一个顺序(与下一个关系)。”你能发布一些简单的 CYPHER 例子吗？这对我来说很难想象。

“图形数据库预先实现关系，并将它们与它们连接的节点一起存储”这是否意味着从性能角度来看，以下两个基本相同？因为这两种关系都连接节点。

CREATE (dgr:Person {name:"Dave Grohl", instrument: "drums"})-[:IS_MEMBER_OF]->(nir:Band {name:'Nirvana'})
CREATE (dgr:Person {name:"Dave Grohl"})-[:IS_MEMBER_OF {instrument: "drums"} ]->(nir:Band {name:'Nirvana'})

Answer 1

你的第二个模型看起来真的很棒。你应该问问自己，你想用它解决哪些查询/用例，如果它支持它们，你就很好。

对于某些特定的用例，将乐队成员建模为节点可能会很有趣，然后您可以将它们连接到仪器节点、时间树(年->月->成员)或将它们放入订单中(与下一个关系)。

关于您关于连接表的问题。

在图形数据库中不需要这些，关系起作用(但不是连接表的实现)。图形数据库预先具体化关系，并将它们与它们连接的节点一起存储。因此，沿该连接进行查询并不昂贵，因为它只是跟踪数据库中的现有记录。

因此您也不需要技术上的主键和外键。唯一有意义的是索引您用来查找实体的属性，例如:Person(name), :Band(name)，流派、国家和城镇相同(如果你想按名字搜索)。

一个可以帮助您入门的好工具是 http://graphgen.neoxygen.io示例图生成器。

如果您有兴趣，我们还有一些关于音乐领域的数据集和文章:http://www.neo4j.org/misc/music (musicbrainz 数据集已过时，必须更新)。