问题标签 [natural-key]

我有 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]
- 这些表格不再更改（无插入）

我有一张记录许可证使用情况的表格。每个许可证使用都需要与用户和主机相关联。表定义如下所示。

我想规范化这个表，以便将重复的用户/主机值移动到这样的新表中。

对于user_host表，我应该选择什么样的主键 - 自然或代理？我可以想到以下控制因素。

1. 如果主键是自然的，即用户名和主机名的组合，则父表per_user_fact不需要额外的连接来查找用户名和主机名。
2. 如果主键是自然的，则会浪费存储，因为用户名和主机名值将在两个表中重复。
3. 如果主键是代理项，则父表将需要额外的连接来获取用户名和主机名的值。
4. 如果主键是代理，对 user_host 表的索引会更快。

请指教。

虽然有大量关于如何建模的信息，但在 JPA (2) 中，一对一关系 或具有自然键的实体，我无法找到关于如何建模的清晰/简单的答案我们两者都有的情况，即父表具有自然键的一对一关系。很明显，我可能错过了这样的教程；如果是这样，将我指向一个也可能是答案。

而且，与 JPA 和像我这样的菜鸟一样，当一个人需要比最基本的模型多一点的时候，一个人很快就会碰壁。

因此，考虑以下数据库模型：

对应的 JPA 注释对象模型是什么？（因为我不想影响答案，所以我不考虑我尝试过的事情......）

也欢迎性能建议（例如“一对多可以执行得更快”等）！

谢谢，

我有一个简单的

并且自然 id 创建了一个唯一的密钥（好！），它使owner休眠状态不可变。这也是一件好事，然而，一旦在一个蓝月亮，管理员需要更改所有者。所以我似乎被迫让它也可变，这真的很不喜欢。

我可以使用简单的 SQL 来克服它，但这意味着撒谎，我也不喜欢这样，因为它可能会欺骗 hibernate 做错事。

我正在寻找一种干净的方式来陈述“除非我说是不变的”这样的东西（尽管我对它的可能感到悲观）。我也很好奇，替代品的缺点是什么。

我看到了这条评论：

[应用程序] 与数据相关的问题最多的是使用自然键的应用程序。

资料来源：代理与自然/业务键

我想要更多的支持证据，因为评论留下了很多想象。

它表明使用自然键的做法会产生与数据相关的问题，但没有具体说明哪里出了问题……数据会损坏吗？不同步？变得错误、丢失、损坏？难查询？

当数据库设计为使用自然键而不是使用代理键时会发生什么数据问题？使用代理键时如何防止这些类型的问题？

多对多表连接两个实体表。我需要多对多表中的一个附加列来表示极性，它应该只有两个值，一个代表正，第二个代表负。

为了实现这一点，我计划添加一个名为的表，该表sign将有一个名为的列sign（这也是表的主键），并且该表将仅包含两个值，一个代表正数，另一个代表负数。

然后可以将上述多对多表sign.sign作为外键包含在内，并且只允许两个值。

如果这是一个糟糕的解决方案，请评论您为什么会有这种感觉以及什么可能是更好的解决方案。

如果一个可接受的解决方案，那么这两个值应该是什么？可能的答案是：

• 正面和负面（不会使用）
• p 和 n（可能不是）
• 1 和 0
• 1 和 -1

我特意包含了这个php标签，以表明我将使用 PHP，因为一种解决方案优于另一种解决方案可能会简化 PHP 实现。

我正在为一个项目编写一些额外的固定装置，并且我有一个关于如何使用自然键的问题。

在另一个夹具中，自然键的area定义如下：

但是，我正在为具有ManyToMany关系的模型编写夹具，那么如何包含多个两个对象键？以下似乎不起作用。

在我们的每日 ETL 负载中，我们正在加载一年前的历史记录，并且该窗口每天都会更改为从 MAX（增量日期时间）值回溯一年。有时，事实数据中的记录是历史更新的，我们将获取该更改并重新处理。

此外，相关维度之一是类型 2 暗淡，并且经常发生变化。类型 2 维度记录的更改可能发生在我们最初提取事实数据和重新处理之间，从而导致该特定维度记录/自然键的新键，其中 IsCurrent = 1。

我们将来自集成层的事实数据合并到来自相关维度的代理键上的表示层。但是，由于发生了类型 2 更改，我们现在有一个用于相关暗淡的新键，我们的 MERGE 将其检测为新记录，而不是看到它已经存在。现在我们在事实表中有重复的记录。

我认为我们可以通过执行以下操作来解决此问题：

• 将维度记录的自然键添加到事实表并更改 MERGE 以使用非类型 2 键和该表的自然键作为使其对 MERGE 唯一的原因。
• 将事实 MERGE 上的 Type 2 键更改为 Type 0（本质上），如果它被检测为新记录但值永远不会更新，则将其插入其中。

这里可能还有其他选择，但这是我首先想到的处理这个问题的方法。我认为这是一个非常常见的用例，我只是想知道最佳实践方法是什么。理想情况下，我们不会重新处理一年前的事实数据，但这就是它的方式。

我目前正在尝试实现我自己的用户模型。因此我创建了一个新的应用程序“帐户”。但是每次我尝试创建新用户时，都会出现以下错误：

AttributeError：“AnonymousUser”对象没有属性“_meta”

帐户-models.py：

之后我跳回 settings.py 并将自定义用户模型添加到我的实际博客应用程序中：

我还添加了

所有这些用户模型/django 的东西对我来说有点新，我不知道错误“AttributeError：'Manager' object has no attribute 'get_by_natural_key'”是什么意思。

感谢：D

在将在全球范围内使用的应用程序中，有哪些好的候选者可以使用自然键来唯一标识用户/人员？

我们如何处理边缘情况？- 没有国家或官方文件的人（难民） - 更改姓名或性别/性别的人

密钥应该是健壮和独特的。