根据字段更改外键答案

【问题标题】：Foreign Keys Changing Based on a Field根据字段更改外键
【发布时间】：2011-08-26 02:09:18
【问题描述】：

在 SQL（特别是 mysql）中考虑这样一种情况，即我有一个表，其中包含一个称为 type 的枚举（名称、关系）和一个称为 idtype 的 int。

然后我有另一个名为 names 的表，它有一个字段 idname 和另一个名为关系的表，它有一个字段 idrelation。

基本上如果 type == name 那么 idtype 是 idname 的外键，如果 type = relationship 那么 idtype 是 idrelation 的外键。有没有办法指定这样的外键关系？或者/还有没有更好、更传统的方式在mysql中表示这种关系？

谢谢，大卫

【问题讨论】：

任何时候你想做这样的事情都表明你的数据库设计存在致命缺陷。

标签： mysql sql foreign-keys

【解决方案1】：

问题是您将两种不同类型的信息存储在一个表中 - 几乎总是一个坏主意 (IMO)。你应该把你的第一张桌子分成两个。另一种选择是有两个字段 nameID 和 typeID - 但我不建议这样做。如果您的表格没有更多细节，我无法提供更具体的答案。

【讨论】：

【解决方案2】：

我通常使用类似于面向对象术语中的继承的东西来建模它。它看起来像这样：

Products
   id (PK)

Widgets
    product_id (FK to Products.id) (PK)
    <widget specific columns>

Whatsits
    product_id (FK to Products.id) (PK)

Product_Types
    type_id
    product_id (FK to Products.id)

这样您就可以将产品类型与任一产品子类型相关联。

您的设计听起来有点“松散笨拙”，但也许那是因为您只是在举一个例子。不过，我建议您了解 EAV 模型以及为什么要避免使用它。我不知道你是否使用了这种模式，但看起来你可能会。

【讨论】：

对我来说听起来也像 EAV。大多数情况下存储数据的最糟糕方式。

【解决方案3】：

这听起来像是在实践中或在典型用户负载下永远无法正常工作的设计。您真的非常需要阅读为什么 EAV 表是一个非常糟糕的设计选择。 EAV 的灵活性是在开发时间以编写冗长、复杂、可怕的查询和性能严重下降为代价的。 EAV 应该只在极少情况下由客户用于非常少数自定义。但是如果你在设计中正确地完成了你的工作，那么 95% 或更多应该是关系建模的。

但是，如果您真的坚持这一点，那么您可以真正执行 FK 关系的唯一方法是通过触发器。不执行它们是一个更糟糕的主意，并且会导致数据损坏。

【讨论】：