gpt4 book ai didi

neo4j - 为什么关系作为一个概念通常存在于 neo4j 或图形数据库中?

转载 作者:行者123 更新时间:2023-12-01 10:51:00 26 4
gpt4 key购买 nike

我似乎找不到关于此的任何讨论。我一直在想象一个无模式、基于节点和分层的数据库,有一天我认为它不存在太常识了,所以我开始四处搜索,neo4j 大约是我想象的 95%。

我没有想到的是关系的概念。我不明白为什么他们是必要的。它们似乎为所有以图形数据库为中心的主题增加了大量的复杂性,但我不太明白有什么好处。关系似乎几乎完全像节点,除了更有限。

为了解释我的想法,我想象着开一家公司,所以我创建了自己作为我的第一个节点:

create (u:User { u.name:"mindreader"});
create (c:Company { c.name:"mindreader Corp"});

有一天我得到了一个客户,所以我把他的公司放到了我的数据库中。

create (c:Company { c.name:"Customer Company"});
create (u:User { u.name:"Customer Employee1" });
create (u:User { u.name:"Customer Employee2"});

我决定将用户链接到他们的客户

match (u:User) where u.name =~ "Customer.*"
match (c:Company) where c.name =~ "Customer.*
create (u)-[:Employee]->(c);

match (u:User where name = "mindreader"
match (c:Company) where name =~ "mindreader.*"
create (u)-[:Employee]->(c);

然后我雇了一些人:

match (c:Company) where c.name =~ "mindreader.*"
create (u:User { name:"Employee1"})-[:Employee]->(c)
create (u:User { name:"Employee2"})-[:Employee]->(c);

有一天,人力资源部说他们需要知道我何时雇用了员工。好的:

match (c:Company)<-[r:Employee]-(u:User)
where name =~ "mindreader.*" and u.name =~ "Employee.*"
set r.hiredate = '2013-01-01';

然后 hr 回来说,嘿,我们需要知道公司中的哪个人招聘了新员工,以便他们可以获得现金奖励。

好吧,现在我需要的是指向用户的关系,但这是不允许的(:Employee 关系和用户之间的 Hired_By 关系)。我们可以有一个额外的关系 :Hired_By,但是如果 :Employee 关系被删除,除非有人记得删除它,否则 hired_by 将保留。

我本可以在 neo4j 中做的只是有一个

(u:User)-[:hiring_info]->(hire_info:HiringInfo)-[:hired_by]->(u:User)

在这种情况下,关系仅提供最少的信息,即名称。

我最初的设想是会有节点,然后节点的每个属性可以是数据类型,也可以是指向另一个节点的指针。在我的例子中,用户记录最终看起来像:

User {
name: "Employee1"
hiring_info: {
hire_date: "2013-01-01"
hired_by: u:User # -> would point to a user
}
}

本质上它仍然是一个图表。节点相互指向。关系的名称只是源节点中的一个字段。要查询它,您只需去

match (u:User) where ... return u.name, u.hiring_info.hiring_date, u.hiring_info.hired_by.name

如果您需要相同类型的一对多关系,您只需要一组指向节点的指针。如果您引用一个集合作为返回,您实际上会得到一个连接。如果删除 hiring_info,它会删除指针。对其他节点的引用不必是节点顶层的无组织列表。此外,当我查询每个用户时,我将知道有关用户的所有信息,而无需查询用户本身及其所有关系。我会知道他的名字以及他在同一个查询中雇用某人的事实。从数据库后端来看,我不确定会有多大变化。

我看到很多人问他们是否应该使用节点或关系来建模这个或那个,偶尔还有人问关系之间的关系。这感觉就像是 XML 问题,你想知道一条信息应该是它自己的标签还是只是它的父标签的属性。

查询引擎煞费苦心地处理关系,因此拥有它们一定有一些巨大的优势,但我不太明白。

最佳答案

不同的数据库用于不同的事情。您似乎在寻找 noSQL 数据库。

您已经涉及到一个非常广泛的主题领域,所以我将简要介绍一下。数据库模式有很多种,每种模式都有不同的用例。

  • NoSQL 又名非关系数据库:

    每个对象都是一个文档。您可以引用其他文档,但任何额外的遍历都意味着您正在进行另一个查询。当您的数据之间经常没有关系,并且通常只想查询一次并拥有大量灵活存储的数据作为返回的文档时注意:这些不是“节点”。节点有一个非常具体的定义,并暗示有边。)

  • SQL 又名关系数据库:

    这是表域,这是外键和一对多关系发挥作用的地方。这里有严格的模式和非常快速的查询。老实说,这就是您应该用于您的用户示例的内容。事物之间关系较浅的少量数据(您不必跟踪关系超过 1-2 次即可到达相关条目)是这些数据的优势所在。

  • 图数据库:

    当关系是您尝试做的事情的关键时,请使用此方法。最常见的图表示例类似于社交图表,您可以在其中将不同的用户连接在一起,并且需要在许多步骤中遵循关系。 (例如,计算两个人是否在深度为 4 的范围内连接)

图数据库中存在关系,因为这是图数据库的全部概念。它并不真正适合您的应用程序,但公平地说,您可以在数据库的节点部分保留更多内容。一般来说,数据库的整体理念是让您可以非常快速地查询大量数据。根据数据的内在结构,有不同的方法是有意义的。因此出现了不同类型的数据库。

在强连接图中,Neo4j 在 1000 倍的数据上比 SQL 数据库快 1000 倍。 NoSQL 可能永远无法在强连接图场景中执行。

关于neo4j - 为什么关系作为一个概念通常存在于 neo4j 或图形数据库中?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/20436476/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com