问题标签 [primary-key-design]

我正在建模一个具有以下实体的投票系统：

• 类别
• 被提名人
• 阶段

顾名思义，我将在各自的表格中存储类别和提名者。投票将分为两个阶段。在第一阶段，每个类别将有 8 名候选人。投票最多的 4 名候选人将进入第二阶段（也是最后阶段）。

到目前为止我有这个结构（简化）

我的问题是如何为投票部分建模。我想我有 2 个选项，但我不确定哪个更好，或者每个选项的优缺点是什么：

选项 1：拥有一个带有复合 3 列主键的 category_nominee 表（我很确定这里的“规范”PK 是由这 3 个字段形成的；不确定性能影响；我使用的是 mysql）

我不喜欢的是，要从投票表中引用 category_nominee，我将不得不再次使用这 3 列，因为我在 category_nominee 中没有单个标识符。因此，在投票表中，我将不得不重复 3 列：

此外，我不确定 category_id 是否应该指向 category.id 或 category_nominee.category_id （我倾向于后者）

选项 2：在 category_nominee 中创建一个自动递增的 id 列，并使 category_id、nominee_id 和 phase_id 成为复合唯一键。

这将简化对 category_nominee 记录的引用并避免一些重复。我希望投票中的记录比 category_nominee 中的记录多得多。我仍然不确定哪个选项更方便。

选项 1 的 SQL Fiddle

选项 2 的 SQL Fiddle

我正在尝试确定在 mongo db 中处理复合主键的最佳方法。本系统中与数据交互的主键由 2 个 uuid 组成。uuid 的组合保证是唯一的，但单个 uuid 都不是。

我看到了几种管理方法：

1. 对由 2 个值组成的主键使用一个对象（如此处所建议的）

2. 使用标准自动生成的 mongo 对象 id 作为主键，将我的键存储在两个单独的字段中，然后在这两个字段上创建复合索引

3. 使主键成为 2 个 uuid 的哈希

4. 我目前不知道的其他一些很棒的解决方案

这些方法的性能影响是什么？

对于选项 1，由于具有非顺序键，我担心插入性能。我知道这会扼杀传统的 RDBMS 系统，而且我已经看到迹象表明这在 MongoDB 中也是如此。

对于选项 2，拥有一个系统永远不会使用的主键似乎有点奇怪。此外，查询性能似乎不如选项 1。在传统的 RDBMS 中，聚集索引提供了最好的查询结果。这在 MongoDB 中的相关性如何？

对于选项 3，这将创建一个 id 字段，但在插入时它也不会是连续的。这种方法还有其他优点/缺点吗？

对于选项 4，嗯……选项 4 是什么？

此外，还有一些关于将来可能使用 CouchDB 代替 MongoDB 的讨论。使用 CouchDB 会提出不同的解决方案吗？

更多信息：可以在此处找到有关该问题的一些背景

我有student table，admission id我想admission id在注册时添加前缀

标准表：

14AD被添加到我想要这样的录取ID

提前致谢

如果主键 (PK) 值在表中是唯一的：

• 防止（或阻止）前导控制字符（例如制表符）是否必要（或可取） ？

背景

诸如在 Microsoft Access 中选择正确的主键（Blue Moose Technologies，2008 年）等文章对用户可能键入的主键值提出了警告。

我读到，除其他外，Access 不允许表具有具有 null 值的主键。

除了空值：Access 2010 确实允许在主键中使用前导制表符……虽然我远非数据库技术专家，但这让我觉得可能很麻烦。

有关的

表中主键的最佳做法是什么？

旧版本 Access 的参考点

用于命名，但不适用于值：

手动创建表 - 编程 Microsoft Access 2000（Microsoft 编程系列）状态：

…您不能以空格或控制字符（ASCII 值 0 到 31）开始字段名称。…</p>

Microsoft 的 Access 2003词汇表指出，与标准命名约定有关：

…您也不能使用前导空格或控制字符（ASCII 值 0 到 31）。…</p>

我目前正在用一个唯一的、自动递增的 ID 列来补充我的表的自然主键。

这使得比较、更新和删除代码中的记录变得更加容易（更简单的 WHERE 子句）。

这与使用 ID 作为主键和 Category/DisplayName 上的唯一键相比如何？

使用一种方法比另一种方法有什么优势吗？

我希望有人能帮帮忙。我正在尝试在下面设置一些东西，但有点混乱。据我了解，为主键派生数字 ID 变量（例如自动递增）比使用定义记录的“自然”变量的复合主键更有效（特别是如果它们是字符变量（以及更多所以如果排序规则是 UTF-8))

如下例所示，每个客户都有一个项目列表 (ITEMID)，它们都是类别 (CATID) 的所有成员，但是，问题是我需要客户另外能够将他们的项目分配为集合的组件set (SETID)，它是一个非识别参考表 - 任何客户都可以拥有一个 SETID 的多个版本。

一组所需的项目由 CATID 指定。因此，在下面针对一位客户的示例中，他们可以选择将项目 2 或 4（或两者都分配）分配给 SET 001。

提前谢谢了！

我在这里读到，使用 AI 整数来表示用户可能比分配的域（字符串）用户名更好。我可以接受，但是，当我在“用户”表中包含自动生成的用户 ID 和唯一域用户名时，我应该如何在其他表中将其表示为 FK？例如。带有'userid' AND 'domainname' 或只是用户ID 的部门表；具有“用户 ID”和“域名”的硬件表或只是“用户 ID”作为所有者？

我正在设计一个 HBase 架构，其行键以反转的域名开头。例如，com.example.www。尽管以or结尾的域要.com多得多，但我假设我不必自己管理拆分，并且可以依靠 HBase 的自动拆分来跨区域分配行。即，区域会随着它们变得太大而分裂。 .org.edu

我最终应该得到更多具有以开头的键的区域，但我com.认为org.这没关系，并且“com.区域”最终应该分布在我的区域服务器上，对吗？

这里的负载平衡有问题吗？在 Lars 的2011 HBase Schema Design 视频中（链接直接转到感兴趣的部分），他讨论了在密钥开头也有反向域的模式设计。该视频称，“出于负载平衡原因”使用了反向域的 MD5 哈希。

我可能遗漏了一些东西......如果some.website.com在我的输入中出现的可能性与 一样another.website.org，这是否意味着每一行都同样可能击中一个区域（甚至一个区域服务器）与另一个区域？

One of my tables order has one to many relationship with two other tables PaymentMethod1 and PaymentMethod2. I have created separate "payment method" tables since they have completely different attributes so that I can avoid nulls. But, a particular row in order will link to a particular row of any one table -- PaymentMethod1 OR PaymentMethod2. This requires the primary key values to be unique in both of these tables, i.e. no two rows in PaymentMethod1 and PaymentMethod2 can have same primary key.

Am I right in chosing primary keys for PaymentMethod1 and PaymentMethod2 in this fashion? If yes, how do I implement it?

我有一个 TCG 卡数据库，我正在尝试确定一个主键。我最初使用代理键解决了问题，但我意识到有时我会忘记添加一些卡片，例如促销卡片。这对于代理键来说是有问题的，因为它们是使用最新的自动增量添加到数据库中的，我不希望它们的 ID 依赖于它们插入的顺序。我在想也许我可以对某些卡片功能进行哈希处理并将其用作主键？

以下面的伪代码为例：

卡的可能数量现在徘徊在 25k 左右，每 6 个月增长 100-300 左右。

1. 以这种速度，不会发生碰撞吧？
2. 这是好习惯吗？我还有其他好的选择吗？

我知道我可以通过将散列转换为来缩短散列，base 62但我会将它们加入到用户的库存表中，所以我认为保留这些int将是最好的选择。