问题标签 [primary-key-design]

我们正在创建一个包含 20 多个表的新数据库，我们的数据库支持：

• 序列。
• 身份列（始终作为身份/序列生成）。

所以，问题是：我们应该使用序列还是身份？哪一个更好？团队似乎在这一点上存在分歧，所以我想听听利弊，以帮助决定。

添加数据库详细信息：

• 我们正在 IBM DB2 上创建新数据库，但我们需要确保它与未来迁移到 PostgreSQL 的计划兼容。

我想通过MySql的语法了解为什么同一个表中不允许两个主键的原因。我了解复合键，这与此无关。

我不明白为什么不允许在同一个表中使用两个单独的主键。但是我们可以将一列作为主键，另一列作为唯一且不为空。它实际上具有两个不同的主键，因为我们可以使用这些键中的任何一个来清楚地识别一行。为什么第一个不允许，而后一个是？

我试图弄清楚逻辑，但偶然发现了 Codd 的 12 条规则中的第 2 条，上面写着

通过使用表名、主键值和列名的组合，可以保证关系数据库中的每个数据（原子值）在逻辑上都是可访问的。

表名、主键值和列的组合对于单个数据值是否应该是唯一的，或者我们可以有多种组合来保证访问？为什么或者为什么不？

编辑：由于该问题被确定为可能重复，我将在下面解释它有何不同 其他类似问题是

我可以在一个表中有多个主键吗？

答案是NO。

我的问题是为什么？原因是什么？

Codd 打算通过第 2 条规则说什么？

如果允许多个单独的主键会出现什么问题？

我们正在构建一个新的 REST API，并且有一些关于主键和幂等键的决定。我们的 API 有很多用户，用户只能查找属于他们的对象。请求经过身份验证，因此我们知道userId与给定请求相关联。

关注的属性：

• userId用户的标识。
• idempotenyKey在对 API 的幂等请求中使用的幂等密钥。每个用户唯一。

假设有一个Cars带有端点的假设表GET .../cars/{id}，我们将以此为基础进行讨论。

选项

选项 1 - 使用 userId 和 idempotencyKey 的组合作为主键

项目查找： GET .../cars/{idempotencyKey}

想法：

• 查找中使用的 id 是可以猜测的。
• 由于对象是经过身份验证的，这似乎不会造成直接的安全问题，但这确实意味着如果 API 中有一个端点允许我们的用户查找某些内容，我们需要假设查找是可猜测的。

选项 2 - 使用 userId + idempotencyKey 的哈希作为主键

插入时我们会计算id = hash(userId + idempotencyKey).

项目查找： GET .../cars/{id}

想法：

• 主键是不可猜测的。
• 这进一步防止了针对ids.
• 不再是复合主键。
• 与选项 3 不同，不需要对 (userId, idempotencyKey) 的唯一约束。

选项 3 - 生成 uuid 主键

插入时我们会设置id = UUID.randomUUID().

项目查找： GET .../cars/{id}

想法：

• id 是完全不可猜测的，并且与任何业务数据无关。
• 需要额外的索引。

选项 4 - 从未向用户公开的自动递增主键

有几种方法可以进行查找。查找可以完全基于 idempotencyKey，即： GET .../cars/{idempotencyKey}

或者，我们可以自动生成一个 referenceId uuid，它将被索引并用于查找。

想法：

• 主键永远不会暴露给用户，这是一种非常常见的做法。
• 如果业务逻辑发生变化，则允许更大的灵活性（尽管对于像 userId 和 idempotencyKey 这样的基本概念，我看不出它们会如何变化）。
• 主键是 INT，因此更小。这允许更小的索引和可以说更高的性能。
• 再次需要一个额外的索引。

寻求有关采取何种方法的建议。围绕性能和规模的考虑非常重要。

谢谢！

我的表没有主键。我想同时使用 userId和cartId。

我应该将 2 列定义为主要列吗？如何？

您可以将自己的 clr udt 作为表上的主键吗？看来您不能 - 我添加了用于二进制序列化和可比较的接口，但是在 PK 约束中使用该类型时，我收到一个错误：该类型不能在主键中使用。

那么-这是否可能，如果可以，我需要使用哪些属性来装饰我的类型以允许它？

*编辑：找到我的问题的线索：来自https://docs.microsoft.com/de-de/sql/t-sql/statements/create-index-transact-sql?view=sql-server-2017 部分“ columns"：如果类型支持二进制排序，您可以在 CLR 用户定义类型列上创建索引。

所以二进制排序需要是“真的”（我的是假的）。现在的后续问题是：如何序列化您的类型（字符串集合）以使其成为二进制可排序的？

-- 背景资料

我想这样做的原因可能是对一个糟糕的初始想法的更糟糕的跟进：我们当前的数据库实现使用复合业务键。复合键的组件不在“许多”列中，而是在一列中与分隔符连接。例如，“jeep-red-ny”可以是描述位于纽约的红色吉普车的行的主键。包含此连接的列就是 varchar(50)。

我想知道是否有一个“专用”类型来承载这三个方面（车辆类型、颜色、城市）是否会使其更好一些。

我想，最好的选择是删除这些连接的键并在不同的列中使用“普通复合”键。具有串联很好，因为整个键是一列，毫无疑问什么属于它，什么不属于它。UDT 将同时提供：包含在一个列中，但可以访问所有组件。

我想在一个有 600 万条记录的表上创建一个主键，但是当我执行这个时：

它正在锁定我的表，而 alter table 没有完成执行......

我有两个表，如下所示。

交易表是代表买方和供应商之间的销售事件的表。表中的 ... 表示其他列，例如 TransactionDate、Store Information 等。

联系表是代表买方和供应商信息的表格，例如姓名和家庭地址等。

现在，这两个表共享一对一的关系，其中 BuyerID = ContactID 和 SellerID = ContactID。

我正在使用 python 脚本填充此表，因此答案可能是 python、SQL 或两者兼而有之。

当前状态

交易表

联系表

我想做的是删除联系人表中的重复行，并使表关系成为一对多。此外，例如，如果 Janet Myers 更改了她的姓氏，尽管所有其他列保持不变，但联系人表中将会有一个新的添加。即忽略ContactID 列，ContactTable 中不应有两个相同的行。

未来状态

交易表

联系表

解决这个问题的第一个想法是从所有其他列的哈希中创建 ContactID。

MERGE然后，如果表中尚不存在 ContactID 哈希，我将使用语句添加联系人。我认为这会起作用，但是我正在考虑冒着与财务数据发生哈希冲突的风险。

除了哈希，我的另一个想法是MERGE声明，但子句中有大约 15 列，ON我认为这将是非常低的性能。

要求是有 2 个实体：学生和学校我需要创建一个休息 api 来读取/更新这些实体。它们之间唯一的共同属性是地址。以下 Db 设计是否遵循 sql 的最佳实践？

• 学生将与学校建立多对一的关系。

• 学生表 -Name -address.id (FK)
  -address.id (ForeignKey) PrimaryKey: 姓名

• 学校：schoolId（自动递增） Name contacts.id（ForeignKey）唯一（schoolId）primarykey：Addresses.Id，schoolId

• 地址：街道城市状态 ID（自动生成） 主键：ID

边问：地址的所有属性都可以构成地址的主键吗？

我有两张桌子。订单和托盘。每个订单可以有多个托盘。我想弄清楚是否可以使 PalletID 成为 OrderID 的扩展。例如，OrderID 为 8000。当将托盘添加到订单时，托盘 ID 变为 8000-1，当将下一个托盘添加到订单时，托盘 ID 变为 8000-2，依此类推。

这可能吗？