问题标签 [surrogate-key]

我在 MySQL 中有一个简单的帖子表，它有一个 POST_ID 作为 SK（代理键）。对原始帖子 ID 的回复存储在同一个表中的 PARENT_POST_ID 列中，但我想执行以下逻辑：

插入之前（我认为...）

如果未在 INSERT 上定义PARENT_POST_ID ，则将行值默认为新生成的 POST_ID（来自 auto-int 序列）

如果在 INSERT 上定义了 PARENT_POST_ID ，则将其设置为已传递的任何内容。

例子

答案在这里：https ://stackoverflow.com/a/11061766/1266457看起来这可能是我需要做的，尽管我不确定它在做什么。

谢谢。

我对仓储很陌生，我在实施代理键时遇到了问题。例如，我有一个客户维度表，它为特定地区的每个客户提供一个代理键。像这样： (SK_NK_Customer_Region) (1, 10022, 22, 100) (2, 10162, 62, 101) (3, 10322, 22, 103), . . . 这些都保存在我的客户维度表中。我的问题是，当交易发生时，如何计算要在事实表中注册为外键的代理键？

我有两个加载语句A和B. 在每一个中，我都有一个代理键。如果两个键都匹配存储的数据，我想匹配代理键列。

我尝试了以下代码。

上面的命令打印所有数据。

我经常看到人们在关系数据库中使用人工/代理键。想一想，在我看来，虽然这简化了连接查询，但它使新元组的插入变得复杂。举个例子：

R1(a, b, c) R2(c, d, e) c 是 R2 的代理主键，由 R1(c) 引用。如果要在R1和R2中插入数据，首先要检查R2中是否已经存在要插入的R2元组，如果存在，则必须获取其对应的人工密钥，以便在元组中引用它对于 R1。

使用自然键： R1(a,b,d,e) R2(d,e) 属性 d 和 e 是 R2 的自然主键集，由 R1(d,e) 引用。如果我想在 R1 和 R2 中插入一个新元组，我可以简单地插入它们，因为对于 R1 元组，我引用的外键（即 R2 主键集的值）是已知的。

我的假设是正确的还是我遗漏了什么？

如果数据库有属性 A1, A2, A3...An 和A1, A2 & A3 可以一起形成复合键，使用代理键而不是复合键更好吗？

使用代理键将提高记录的插入执行速度（这支持复合键的代理）但是如果我们使用代理键（这支持代理键上的复合键）。

在这样的条件下，哪个性能更好？代理键还是复合键？

我有 5 个要导入 MySQL/MariaDB 数据库的文本字段。但是有两个问题：

(1) 文件非常大：0.5 GB 到 10 GB
(2) 所有相关键有 40 个字符

第（1）点我必须接受它，我不能改变它。第2点是我关心的。网上有很多建议。例如，将枚举用于 varchar 或使用数字代理。将代理键添加到表中没有问题。但是必须将相同的代理键添加到其他表中。这就是我坚持的地方。

这里是有关文件/表的具体信息：

• 表invoice有 3 列和 20 Mio 行：

  • 具有不同值的 invoice_id（主键）= 行数
  • 具有 4,000 个不同值的 praxis_id
  • 具有 4 个 Mio 不同值的患者 ID，所有列都是 CHAR(40)，并且具有 40 的固定长度。

• 表诊断有 3 列和 25 Mio 行：

  • invoice_id CHAR(40) 1.4 Mio distinct id
  • 诊断类型
  • 诊断代码

• 表患者有 5 列和 5 Mio 行：

  • patient_id CHAR(40) 不唯一（4 Mio distinct pat_id）
  • praxis_id CHAR(40)
  • 出生年份、性别等

例如，我想将发票与诊断和患者一起加入。索引键是有意义的。一种方法是将 invoice.invoice_id 定义为主键，对于表 invoice 中的所有其他键，我将添加一个索引。与表诊断（invoice_id with INDEX）和患者（patient_id 作为主键）相同。
问题是使用以下命令将 invoice.invoice_id 定义为主键需要很长时间：

一小时后，我终止了该过程。我认为性能问题是由表 invoice 中 invoice_id 的数据类型引起的。一个想法可能是在加载文本文件时添加一个自动递增代理键 invoice_id_surr。但是，如果我想加入表诊断，问题仍然存在，因为我必须加入表诊断的 invoice_id，它没有代理键 invoice_id_surr 作为外键。我可以在 diagnostic.invoice_id 上添加一个索引，但随后我失去了在表格发票上拥有代理键​​的优势。

我会对如何处理这个问题的策略感兴趣：几个已经存在的表可以连接在一起，但键是 CHAR(40) 并且没有索引。

感谢帮助。

更新 1：表格规范
- 键有 40 个字符 [0-9][AZ]
- 这些表格不再更改（无插入）

我必须设计一个表来存储一些远程数据。我通过网络服务获得的数据有一个候选键，由两列组合而成，但我看到很少有帖子不鼓励在休眠中使用复合键，而是建议使用代理键。如果我使用复合键设计一个表，那么我可以直接更新数据，但如果我使用代理键，那么我必须在更新之前先获取主键。我的问题是我应该使用哪一个，复合键还是代理键？

我正在创建一个银行数据库，我在这里遇到以下问题。

假设 CustomerA 有一个帐号 4444，通过它我可以访问与客户相关的所有详细信息，我有一个单独的主键，但我通常会查询这个帐号。

现在，由于某种原因，客户 A 的帐号从 4444 更改为 5555，并且新客户 B 的帐号被指定为 4444。

我希望我的数据库能够处理这样的变化，我应该采用什么方法？

我开发的方法是：为帐号分配时间戳，这将有助于我有效地查询以找出当前帐号相关的客户名称。

但我无法设计一个查询：

• 当我使用 4444 访问 CustomerB 时，仅显示与 B 相关的当前详细信息，而不是 4444 指向 CustomerA，并且
• CustomerA 被 5555 访问时显示所有详细信息，包括由 4444 存储在数据库中的详细信息

我的问题是关于自然键和 auto_increment 整数作为主键。

例如，我有表A和B和A_B_relation。A 和 B 可能是某个对象，A_B_realtion记录了 A 和 B 的多对多关系。

A 和 B 都有自己的全局唯一 id，例如 UUID。UUID 对用户可用，这意味着用户可以通过 UUID 查询 A 或 B。

有两种方法可以设计表的主键。

1. 使用 auto_increment 整数。A_B_relation将整数引用为 FK。
2. 使用 UUID。A_B_relation将 UUID 引用为 FK。

例如，用户想通过 A 的 UUID 查询与 A 关联的所有 B 的信息。

对于第一种情况，查询流程是这样的：

对于后一种情况，流程如下：

所以我认为，后一种情况更方便。这是正确的吗？后一种情况的不足是什么？

我想为 hive 表创建一个代理键，但每次将数据放入表中时都可以复制一个代理键。其他表将通过代理键引用该表，并且可以重新生成该表以添加更多行，并且该关联不会被破坏。我的想法是基本上有一个表中所有列的复合键。

连接我的所有列并将该字符串的 md5 哈希用作对该行的简单查找是否合理？

我在此解决方案中看到的问题是：

• 如果行中的数据发生变化，关联仍然会被破坏
• 无法真正保证哈希值是唯一的（尽管使用我的数字，冲突的可能性很小）

数据注释：

• 数据按天划分，每天大约有 100k 行。
• 在某些情况下，两行具有完全相同的数据，如果它们最终具有相同的键就可以了。