键值存储和关系表可以相互转换吗？答案

【问题标题】：Can a key-value store and a relational table be converted to each other?键值存储和关系表可以相互转换吗？
【发布时间】：2019-04-21 20:15:20
【问题描述】：

可以将键值存储转换为关系表，其中只有两列，表的主键是键值存储的“键”？
可以将关系表转换为键值存储，其中键是主键，值是其他列桌子？
例如，Spanner 是一个列式数据库。从 https://research.google.com/archive/spanner-osdi2012.pdf,为什么可以 Spanner 被视为键值存储，而不是关系？我不很明白“行必须有名字。更准确地说，每个表需要有一组有序的一个或多个主键列”

Spanner 的数据模型不是纯粹的关系，因为 行必须有名称。更准确地说，每张桌子都需要有一个有序的一组一个或多个主键列。这个要求在哪里 Spanner 看起来仍然像键值存储：主键构成一行的名称，每个表都定义了一个来自主键的映射列到非主键列。一行只有当为行的键定义了一些值（即使它是 NULL）。强加这种结构很有用，因为它允许应用程序通过他们选择的键来控制数据的局部性。

【问题讨论】：

如果你不能回答前两个问题，你应该阅读一本关于信息建模、数据库设计和关系模型和/或键值存储的教科书介绍。更不用说解释了 3. 关系模型数据结构完全是关系变量的集合，其中包含多列值的行集。目前尚不清楚引用的意思是什么，因为关系行在表中是唯一的，所以确实有一个子行充当“名称”，尽管任何其他结构都是非关系的。 SQL 有重复的行，他们可能认为“关系”意味着“SQL”。
谢谢。 “关系行在表中是唯一的”。您认为前两个问题的答案都是肯定的吗？
前两个问题定义明确。据我所知，我对前两个问题的猜测都是肯定的。
“KV”没有单一的明确含义。什么是“可以转换”？你建议的结果设计能被合理地使用吗？所以1和2不清楚。您对 KV 的概念与论文/报价中的相同吗？报价太不清楚了，我们不知道它在说什么。这似乎是对 contaning exposition 内容的总结，所以请阅读，这也应该澄清他们对“关系”和“键值”的使用。 PS要在主题上提出一个特定问题，请在您遇到的某个地方提出问题。这不清楚（因为您对 KV 的使用和报价不清楚）并且如果澄清将过于广泛。而且没有研究。 How to Ask
@philipxy 您可以使用您所知道的最常见或最准确的定义

标签： relational-database key-value-store google-cloud-spanner

【解决方案1】：

Re:3，该论文的断言是 Spanner 的数据模型不能被认为是严格意义上的“关系”，因为关系模型没有行名（即主键）的概念。在Relational model 中，Relation 被定义为一组 n 元元组。这意味着根据定义，关系不能有重复的行并且不对其行进行排序（一个集合不能有重复的元素并且不定义其元素之间的任何顺序），因此，在关系数据模型中，行名称又名“主键” ' 不需要标识一行（整行基本上是主键），而 Spanner 要求每个表（RDBMS 对“关系”的理论概念的近似）要么具有唯一的主键，要么只有一行.

具有“行名”或“键”的要求是键值存储的特征，因此从这个意义上说，Spanner 可以被视为键值存储。

【讨论】：

RM 确实有一个标识行名的概念，即超级键，其中包括 CK，其中包括 PK。此外，KV 存储具有完全相同的名称概念，因为 K 是超级键的类似物。和你写的相反。在某些意义上，“行名”是非关系的，但这种意义上也是非 KV 的。无论如何，尚不清楚文章中的“关系”或“KV”或“行名”是什么意思，或者它对 Spanner 表的含义是什么。 PS你是什么意思，“关系模型没有行名的概念（即主键）”？ “PK”是一个 RM 术语。
我的意思是“关系”的数学概念不依赖于“键”的概念（假设这就是作者所说的“行名”的意思）。如果您认为“关系模型”包含“关系”+ FD 的概念，那么“没有主键概念”的说法是不正确的。
但是，如果您只谈论“关系”的概念，那么尽管您始终可以将关系上的键定义为在功能上确定任何属性的最小属性集该集合中的元素，关系的存在不依赖于键。在 RDBMS（实现理论关系模型的应用程序）的上下文中，这基本上意味着您可以拥有一个没有任何主键列的表（数据库系统，如 postgresql 允许它），但您不能在 Spanner 中拥有它。
每个关系都将其所有列作为 supekey，因此将其作为行的“名称”。您的帖子不清楚，无论您想说什么，“关系模型没有行名的概念”都是错误的，并且报价和论文不清楚。当然，他们试图说像 Spanner 的结构这样的东西可以被视为具有 K 和 V 列的关系设计的特例。但除此之外，没有什么是清楚的，包括他们认为“关系”是什么意思。报价一团糟，论文很差。