问题标签 [surrogate-key]

假设一个表使用自然键并且有许多现有的行。改造代理键列并使用 MySql 用唯一值填充它的最简单方法是什么？

即变换

到

并用有效的 id:s 填充新的 id 列。

谢谢/埃里克

Entity Framework 神奇地将下表结构解释为多对多关系。

但是如果连接表有任何附加字段，它将被解释为两个一对多的关系。

我正在使用一个数据库，其中连接表有一个代理键作为主键。因此，EF 将其解释为两个一对多的关系。

是否可以修改 EF:s 解释以使其成为模型中实际的多对多关系？可以使用设计器完成吗？

我正在维护一个数据仓库，其中包含关于必须合并的一类实体的多个数据源。每个源都有一个自然键，并且应该发生的是，始终为每个自然键创建一个且只有一个代理键。如果来自一个源系统的具有特定自然键的一条记录与来自具有不同自然键的另一个源系统的另一条记录表示相同的实体，则将为两者分配相同的代理键。

换句话说，如果源系统 A 具有与源系统 B 的自然键 DEF 表示相同实体的自然键 ABC，我们将为两者分配相同的代理键。该表如下所示：

这就是计划。但是，这个系统已经生产了一段时间，代理键分配是一团糟。在源系统 B 知道之前，源系统 A 会在某一天给出自然键 ABC。DW 为其分配了代理键 1。然后源系统 B 开始给出自然键 DEF，它表示与源系统 A 的自然键 ABC 相同的东西。DW 错误地给了这个组合代理键 2。该表如下所示：

所以仓库乱七八糟。还有比这更复杂的情况。我有一个很短的清理时间表，需要找出一组干净的自然键映射的代理键。

一点谷歌搜索表明，这可以建模为非二分图中的匹配问题：

维基百科 - 匹配

MIT 18.433 组合优化 - 非二分匹配讲义

我需要 Edmond 的路径、树和花算法的易于理解的实现（不是最佳执行）。我没有正式的数学或计算机科学背景，我所拥有的是自学的，而且我今晚不在数学上。任何人都可以帮忙吗？一个指导我实现的写得很好的解释将不胜感激。

编辑：

数学方法是最优的，因为我们想要最大化全局适应度。贪婪的方法（首先获取 A 的所有实例，然后是 B，然后是 C...）会将您绘制到局部最大值角落。

无论如何，我把这个推回业务分析师手动完成（全部 2000 万）。我正在帮助他们评估全局匹配质量。这是理想的，因为无论如何他们都是签字的人，所以我的背面被遮住了。

不使用代理键不会改变匹配问题。仍然需要发现和维护 1:1 自然键映射。代理键是一个方便的锚，仅此而已。

我正在使用 PHP、AS3 和 mysql。

我有一个网站。一个flash(as3) 网站。flash网站通过php将会员信息存储在mysql数据库中。在“成员”表中，我将“id”作为主键，将“用户名”作为唯一字段。

现在我的情况是：当flash想显示一个会员的资料时。我的问题：

1. Flash 是否应该将成员“ID”或“用户名”传递给 php 来处理 mysql 查询？

2. 传递“id”或“用户名”有什么不同吗？

3. 哪个更安全？

4. 你推荐哪一个？

我想在安全性和性能方面优化我的网站。

我正在将现有的数据库结构映射到 Django 模型中。我有一个多对多结构，其中关联表是自然键控的：

有没有办法让 Django 的 ORM 映射这个？我必须更改 foo2bar 以使用代理键吗？例如

我意识到可能会有类似的问题，但我找不到足够接近指导的问题。

鉴于此规范，

我提议的设计/实现是

这有什么问题吗？在这里可以将 SeriesID 代理作为外键吗？我不确定我是否遗漏了任何可能出现的明显问题。还是使用复合自然键（SiteID+SeriesCode / SiteID+EpisodeCode）会更好？从本质上讲，这会将 Episode 表与 Series 表分离，这不适合我。

值得补充的是，在将填充这些表的原始输入数据中，SeriesCode 看起来像“ABCD-1”，而 EpisodeCode 看起来像“ABCD-1NMO9”，所以我想这是可以改变的另一件事。

*：“虚拟”外键，因为之前上级已经决定我们不应该使用实际的外键

提前抱歉，因为这个问题与其他问题相似（但不一样！）。

无论如何，我需要能够在多个位置生成代理键，以便以后同步。我正在考虑使用 GUID，但是这些键可能必须出现在 URL 的参数中，并且 GUID 会非常复杂和丑陋。

我正在考虑一个允许我使用整数的方案，在数据库中提供更好的性能，但显然我不能简单地使用自动数字。这个想法是使用具有两种含义的键——我相信它被称为高低策略。密钥将由源（生成它的位置，通常在此业务案例中的 2 个位置中的 1 个）和自动递增值组成。例如：

1-000000567, 1-000000568, 1-000000569, 1-000000570, ...

对于另一个来源：

2-000000567, 2-000000567, ...

这也意味着我可以将它们作为整数存储在数据库中（即“2-000000567”将变为整数“2000000567”）。

任何人都可以看到这有什么问题吗？比如可能出现的索引或碎片？或者甚至是更好的方法？

只是为了确认一下，这个键没有商业意义，用户永远不会看到它（除了可能在 URL 的参数中）也不会使用它。

我期待您的意见并感谢您的时间，谢谢一百万:)

谁能告诉我代理键（数字或varchar2）的最佳数据类型是什么？我读过代理键最适合数字类型。但是性能是否严重与数据类型有重大影响。它也依赖于数据库吗？

将不胜感激！

我一直在阅读 Stack Overflow 和其他网站上关于复合键与代理键的激烈辩论，尽管对给出的一些论点感到困惑，但我觉得我知道每个论点的优缺点。

我很想去代理键，但现在我有另一个问题。让我解释一下我的情况。我有一个由 5 个整数组成的表，这些整数组成了一个唯一的组合，并且我有几个表引用了这个实体。现在所有表都包含完整的 5 个字段，并且所有 JOIN 操作都必须提及所有 5 个字段作为连接标准。现在我添加了一个代理键。但是我应该从所有表中删除所有 5 个字段以支持引用“主”表的代理外键吗？

我不确定是否要这样做，因为这 5 个字段中的每一个字段都经常被用作其他表中的选择标准。我以某种自然顺序在它们上定义了索引，以便选择操作执行得更快。如果我将所有 5 个字段迁移到一个单独的表中，恐怕当我想选择前三个时，我必须定义一个 JOIN 并从中选择，但不会定义任何索引在那个 JOIN 上，因为它刚刚生成，我将遭受性能损失。

或者我应该以某种方式为每个表定义一个视图，包括 5 个键，并在其上建立索引？

我感到困惑，在输入所有这些之后，我倾向于再次使用自然键。帮助？

我必须修改 Oracle 10g 数据库中包含数千条记录的现有表，以添加代理自动编号键。我想到的一种方法是

1. 创建一个新序列
2. 创建 id 列，允许空值
3. 用序列更新 id 列
4. Alter table 为新的 id 列添加“not null”和“primary key”

有没有更简单或更有效的方法来做到这一点（或者有什么原因导致这不起作用）？