键是什么意思(键和键是哪个)

在前两篇文章中，我们讨论了图形数据建模的各个方面，比如类别变量，以及关系是如何工作的。在本文中，我们来解决如何用键识别图表中的事物。

什么是键？

图形关键字是属性或一组属性，可以帮助识别图形中的节点或关系。

它们经常被用作图遍历的起点，或者作为约束条件。

我们想要什么键？

在我们的Secondary中的键进入不同的选项之前，让我们列出一个非常好的数据库键的属性。

所有者：我们必须知道谁负责键。有人必须发出它，有人不得不说那是哪个。这可能是数据库本身，可能是应用程序开发人员，或者可能是某些外部权限（例如，如果您使用驱动程序的许可证号作为密钥，则为您的本地DMV）。稳定性：数据在我们周围不断变化。我们希望稳定的标识符，使旧系统和代码可以参考较新的数据。唯一性上下文：当然键必须是独一无二的，但它们在某种情况下是独一无二的。驾驶执照ID仅在美国的某个州范围内是独一无二的（它可以在其他地方重用）。透明度：这意味着，键是内部含义吗？一个人可以通过查看前一个人来猜出下一个键吗？如果您看到了像“2020-06-19-ABC”这样的键，那么您可能会推断键值是具有后缀的日期，这不会是不透明的。这样做有一个权限，您可以为您或您可以与之生活的第三方，发布有关如何做出有意义的事情的规则。无论权威是什么，无论是你还是第三方，知道它是谁。使用单个属性，并对其进行唯一的属性约束，这将确保您的密钥无法复制并添加快速查找的索引。具有尽可能宽的唯一环境，以防止您重复失败。使用不透明标识符。这足以让键是独一无二的，不要试图用额外的意义定义它。不要这样做不要使用智能键

智能密钥通常是将信息编码到密钥中的复合值。假设我们有一个订购系统，我们已经确认客户订单是2020-06-19-VA-9912。它似乎可以轻松地对订单日期(2020年6月19日)、订单状态(弗吉尼亚州)和订单编号(9912)中的单键进行编码。在实践中，智能密钥通常以失败告终有几个原因:

如果订单的日期输入不正确，则记录的ID需要更改（？！？！）。它鼓励其他开发人员试图“解析ID”以提取信息，这是一种痛苦，并且可以给出错误的结果（如果订单号更改！）。

关于智能按键的关键点在于，它们总是具有低不透明度；这是他们的观点。

不要在图中使用复合键

在关系数据库中，通常定义两个或更多属性的复合键，但在我看来，这在图中从来没有意义。人们通常使用组合键的常见原因是因为列之间的依赖关系。例如，也许您的客户代码+状态代码是唯一标识记录的原因。但是由于该图允许您拥有您想要的节点，因此该密码:

MATCH(r:Record { ccode:& # 34；X & # 34，scode:& # 34；Y & # 34})通常比这更糟:

MATCH(:A { scode:& # 34；Y & # 34})-[:LINKED _ TO]-& gt；(r:Record { ccode:& # 34；X & # 34})重点是，在大多数情况下，一个好的数据模型可以消除对复合键的需求。

在Neo4j中的选择是什么？neo4j内部ID

每个节点和关系都将获得自己的“内部”标识符，您可以访问id()函数。

这些身份证的好处是，保证永远为你服务。由于内存工作中的图形存储模式，通过ID进行搜索在Secondary中非常快。然而，由于许多原因，内部节点ID(在我看来)提供了非常糟糕的应用程序标识符:

他们被重用了。它们保证在图形中是唯一的，但如果删除节点25并继续创建数据，则稍后可能有不同的节点25。它们不在数据库之间跟踪。如果将所有数据从系统A转储并将其加载到其他系统B中，则不一定具有相同的ID。因此，它们对于在不同的数据库中连接数据，例如使用Neo4j Fabric。

基本上，您得到的唯一保证是它们在全球范围内是唯一的(对于图表，而不是DBMS)。虽然这是不透明的，但标识符的权限是数据库(而不是您的应用程序)，唯一性上下文只选择到单个系统上的单个图。

全球独特的ID

使用Apoc的内置UUIDS，您可以像这样创建它们:

CREATE (m:Thing { id: apoc.create.uuid() });

这些都很好，因为你是权威，自己管理。它们是稳定的，永远不需要改变。它们在所有环境中都非常独特，而且非常不透明。它们是128位的数字，是伪随机产生的。其实不用担心碰撞，因为空太大了。如果你像这样产生103万亿个标识符(我们很确定你会在那个下面)，碰撞的几率仍然是十亿分之一。够了。

它们也带来缺点。

它们是大而笨重的，并且包含比标识符所需的更多数据，这意味着当您有数十亿个时，它们会占用空间。他们对人类可读性保持敌对，如果您的ID在URL中最终有任何内容，这可能很重要，这很常见。别人的身份证

面对现实吧，通常我们的源数据来自其他地方。如果我们将Twitter上的推文导入到图形中，那么所有推文都有现有的ID。通常，一个好的方法是导入数据附带的另一个人ID方案。

很难说这个方法是什么，因为它取决于标识符是什么。我们能做得最好的是回到我们正在寻找的那些原则(不透明性、独特性等。)并评价一张身份证。

我们可以谈谈采用别人标识符的具体否定:

权威：你不是。这意味着您可以信任您数据的某些元素对此外部权威的ID。这是一个问题吗？取决于你的情况。也许，也许不是。混合能力：您的图表现在可能有一个馈线源（例如，Twitter）。当您开始导入其他来源时会发生什么？如果您带入Facebook帖子，您是否有两个标识符，或者ID依赖于源代码吗？这很快就会得到丑陋。

作为一个一般的建议——总是存储你能掌握的任何上游标识符。但是不要用它作为你的标识符。它与上游系统相关联。除了存储远程标识符之外，选择您自己的ID没有任何问题。

自动递增数字

一种常见的方法是使用自动递增编号。Neo4j是否支持这种情况，但在其他库中也很常见，是关系世界的常用技术。这通常不是最好的方法，因为:

如果每个节点标签获得是自己的“递增器”，则ID对图形并不是真正的唯一标签。这使您的密钥隐式ID +标签，而不仅仅是ID。这是你可以选择的最弱“唯一性的范围”。它具有与Neo4J内部ID相同的潜在重用弱点。

据说这种方法还是不透明(好)由你控制(好)，紧凑/存储效率。

关系标识符

作为Secondary 4.1.0，数据库没有传统的B树关系属性索引(它支持关系属性的全文索引)。这具有重要的后果，并且意味着不可能快速找到个体关系的ID，因为数据库根本不能存储它。查找关系的方法是查找一个(或两个)事件节点，如下所示:

MATCH(a:Person { id:1 })-(r:KNOWS)-& gt；(b:Person { id: 2 })返回r；在这种情况下,“从”和“到”节点被有效地用作关系键。id()函数仍然有关系。它们都有内部二级id，但是通常我们不需要给关系分配属性id。不仅可以这样定位，而且没有属性索引，按键查找无论如何都不会是一个有效的方法。

本文是系列文章的一部分；如果觉得有用，请考虑看别人关于标签、关系、超级节点、分类变量的文章。

(本文翻译自大卫·艾伦的文章《图形数据建模:关于键的一切》，转载请注明出处。原文链接:https://medium . com/secondary/graph-data-modeling-keys-a5a 55334 a 1297)