确定多个 MySQL 表的正确键值答案

【问题标题】：Determing correct key values for multiple MySQL tables确定多个 MySQL 表的正确键值
【发布时间】：2011-10-16 09:04:00
【问题描述】：

我正在尝试确定表格需要以何种方式链接。

员工表直接链接到提供更多信息的许多表。其中一些表格有更多细节。

员工有一个唯一的employeeid ~~但我知道最好的做法是仍然有一个id？~~
客户拥有唯一的 customerid
员工有经理
经理是员工
客户有一个与他们关联的~~经理。~~与他们关联的经理
员工可能拥有学术、认证和/或专业信息。

说了这么多，创建主键和外键的最佳建议是什么？有没有更好的方法来处理设计？

编辑

更新图表以反映迄今为止的反馈。查看 cmets 了解正在发生的变化。

【问题讨论】：

在进行任何类型的实施之前，您的图表仍然需要（大量）工作。随着到目前为止的进展，我建议你现在专注于它的一小部分并制定每个部分。您可以针对问题的每个较小部分提出一个单独的问题，然后简单地将它们粘在一起。
例如，我会首先关注Party、Customer、Employee、Manager。但是在你发布另一个问题之前——考虑到你的键仍然没有正确传播——阅读超类型/子类型模式（类别）这里是一个查看stackoverflow.com/search?q=user%3A196713+subtype的链接
我同意，绝对没有为任何类型的实施做好准备。我将发布另一个问题，以确定哪些表需要与它们关联的主键，哪些不需要。

标签： mysql database-design foreign-keys primary-key entity-relationship

【解决方案1】：

虽然您的问题是明智的，但在您进一步设计之前，我建议您花一些时间了解关系、外键以及它们如何通过关系传播。

图表完全错误。它将帮助您开始使用全名TableNameID 命名主键，例如EmployeeID；那么密钥如何通过关系传播就变得很明显了。如果你有全名，你会注意到你所有的箭头都指向错误的方向；父母和孩子颠倒了。无论如何，需要一些练习。所以我建议你重新设计图表并发布新版本，以便我们对此发表评论。它应该开始看起来像这样（只是一小部分）

编辑

这应该为您指明下一步。看看你是否能同时阅读描述（规范）和图表。

每个员工有一个经理，一个经理管理许多员工。
经理是员工。
每个客户都由一名员工管理，该员工担任该客户的客户经理。
客户的帐户管理可能会随着时间而改变。
每个员工都是一个团队的成员，每个团队都有很多员工。
随时间推移跟踪每个员工的员工绩效。
员工可能有很多凭证，每个凭证只属于一个员工。
证书是学术或专业。

【讨论】：

感谢您的示例。我想我可能已经掌握了窍门。随时查看更新的问题和图表并提供更多反馈。
@Astron;好吧，在小步骤。类别符号用于IS 类型的关系——例如Manger IS Employee。好吧，客户订单不是员工，也不是计费。您可能没有注意到，但是当您使用类别符号时，超类型表的主 ID 应该会传播到所有子类型中。我将发布我的答案的更新，这应该会推动您迈向下一步。
很好的信息。为什么您的 Employee 表会循环回自身？每张桌子都必须有一个唯一的ID吗？例如，我更新的图表中的 manager 表可以，但 reporting* 表没有。关于经理，既然现在有一个全局 partyid，我还需要为我的客户表引用一个特定的 manageid 和 employeeid还是 partyid 就足够了？
@Astron;管理者的自我参照关系。每个员工都有一个指向他/她的经理（也是员工）的链接。
@Astron;经理是员工，所以他有一个EmpoyeeID。密钥EmployeeID 传播到Manager 表中。 Manager 表仅包含特定于经理的字段，而其他员工则没有。

【解决方案2】：

员工拥有唯一的员工 ID，但我了解最佳做法是还有身份证吗？

没有。（但请继续阅读。）在两种情况下您需要一个 ID 号：1）当您没有任何其他方式来识别实体时，以及 2）当您试图提高连接性能时。这并不总是有效的。 ID 号总是需要更多的连接，但是当关键信息以人类可读的代码或自然键的形式携带时，您不需要连接即可获得它。此外，ID 号的常规使用通常会引入数据完整性问题，因为通常会忽略对自然键的唯一约束。例如，州名称的 USPS 邮政编码是唯一的，但使用 ID 号而不是 USPS 邮政编码的表通常会忽略该两字符列的唯一约束。在您的情况下，无论如何，您都需要对员工人数进行唯一限制。（但请继续阅读。）

员工有一个经理。

表“团队”是否实现了这个要求？如果“经理”表标识经理，那么您的其他经理列应引用“经理”。（在此图中，即客户、团队和客户订单。）

经理是雇员。

并且该信息存储在“manager”表中？

客户有一个与之关联的经理。

每个订单也是如此。你是故意的吗？

员工可能拥有学术、认证和/或专业信息。

但显然，除非您先存储技能，否则您无法记录任何信息。这听起来不是一个好方法。多考虑一下。

每当您设计带有重叠谓词（重叠含义）的表格时，您都需要停下来坐几分钟。在这种情况下，表“employees”和“customers”的谓词重叠。

如果员工可以成为客户，几乎是所有企业的情况，那么你就为更新异常做好了准备。员工的姓氏发生变化。显然，您必须更新“员工”。但是您是否也必须更新“客户”？你怎么知道？您无法真正分辨，因为这两个表具有独立的 ID 号。

一条非正式的经验法则：如果任何现实世界的实体在您的数据库中有多个标识它的主键，那么您就有问题了。在这种情况下，同时也是客户的员工将有两个独立的主键来标识该人——一个员工 ID 和一个客户 ID。

考虑添加一个人员表，其中一些人是员工，一些人是客户。如果您的数据库设计良好且有用，我敢打赌，以后有些人将成为潜在客户，有些人将成为求职者，等等。你将需要一个人的身份证号码，因为在最一般的情况下，你可以指望知道他们的名字。

在某些时候，您必须将您的数据库设计知识提升到一个新的水平。要尽早开始，请阅读此article on people's names。

【讨论】：

非常好的观点，非常有见地。在这种情况下，客户和员工确实具有唯一标识。假设 customerid 是 c0001，employeeid 是 e0001。其他一切都可以使用自动递增的数字。我已经更新了图表。看看，让我知道你的想法。
两个独立的表中的两个独立的唯一标识符标识一个人是一个问题，而不是一个解决方案。也许我没有说清楚。考虑将所有人放在一张桌子上，而不是两张。
您对唯一标识符非常清楚。员工拥有公司提供的自己的唯一 ID。外部客户没有公司创建的唯一标识符，因此为他们制作了一个标识符，因此将它们放在单独的表中的原因。在提前考虑时，我不想使用与新员工相同的数据格式，因为可能会为新员工分配一个现有客户 ID 的员工 ID，我们只是为了使其正常工作。您是否建议有一个带有 employee 和 customer 表参考的 people 表？谢谢
是的。所有人共有的属性（姓名等）都在人员表中；员工特有的属性（员工身份证号）进入员工表；客户独有的属性进入客户表。 “派对”更笼统；所有组织和个人都是政党。地址参考方、电话号码参考方等。（因为组织和个人都有地址、电话号码等。）
Global 在这种情况下是个好词。细节取决于您是否需要独家弧线。当事人之间，“人”、“组织”是排他性的；每一方要么是一方，要么是另一方，而不是两者。这个 SO 答案有各方的源代码：stackoverflow.com/questions/5466163/… 您可以使用具有这种结构的外键关系将几乎任何东西与任何东西联系起来。