数据体中的元组对组合元组和组件组

Question

tuple、复合元组和components在数据体中有什么区别？

我发现这是最难理解模式的方面之一。我发现这些文档(总的来说很棒)在从头开始解释这件事时不够清楚，也许是因为缺少例子，而且还没有找到关于它的讨论，无论是最新的还是其他的。

以下是我所发现的(这可能是错误的)：

• 元组看起来有点像postgres中的数组。
• 复合元组似乎可以添加复合键，即跨多个属性的唯一性。
• 组件是如何定义类似结构的文档，主要是为了获得级联删除。

Answer 1

数据体中的元组添加了一个更灵活的唯一性约束，并允许您预先计算最佳连接，仅此而已。

来自数据体博客(发布说明)：

您可以使用元组在域实体上创建多属性唯一键。您还可以使用元组优化查询，否则必须连接两个或多个高人口属性。

数据体之所以有3种元组，是因为需要齐次可变长度元组来定义异构固定长度元组，然后需要定义复合元组。

那么复合元组就是方便的了。

虽然元组听起来像是你想要的东西，但是你失去了一些灵活性。例如，如果您没有要查询的底层属性，则不能使用VAET索引(假设其中有一个:db.type/ref )。这就是为什么我相信元组是一个性能特性的顶部，你应该坚持只组合元组，而不是麻烦的其他类型。

例如，如果您需要这样做，就不能将元组属性放在复合元组中，但是如果您的所有元组都是复合元组，则可以这样做，因为它只是一组不同的属性。

不应将元组视为架构的一部分。相反，把它们看作是你为了方便某些事情而嫁接在上面的东西。

关于组件，我将给您一个JSON文档的类比。引用该文档中的结构的属性是组件。组件因为它们的行为方式而不应该共享(不是因为您不能)。因为当您撤回一个实体时，它也会撤回它所引用的所有组件。这就是为什么你不共享组件。回到JSON文档，文档中的任何对象或数组都是根的一个组件。当然，组件可以有组件。您可以将这种结构看作是一种合理的数据单位，但它是一种更为复杂的结构。

Answer 2

关于组件，以及您可能想使用它们的原因，我发现David Nolen在“客户控制中的客户”中的原则非常有用：

理想性质

1. 客户端可以请求他们所需要的精确的总响应。
2. 客户端可以在不牺牲关系查询服务器端的情况下对数据树进行原子提交。

广义地说，isComponent是帮助实现这些原则的一种方法。

并从博客条目引入组件：

组件允许您使用嵌套映射创建大量的数据树，然后将整个树作为生命周期管理的一个单元(特别是回缩)。所有嵌套项作为查询的第一类目标仍然可见，因此您的数据在事务处理时的形状并不决定查询的形状。与行、列或文档存储相比，这是数据体的一个关键价值命题。

要说的更多，我们需要通过一些详细的例子。