数据库表结构答案

【问题标题】：Database table structuring数据库表结构
【发布时间】：2012-02-02 11:19:49
【问题描述】：

我对如何重组我的数据库有点困惑，目前我正在处理三个表：

Items：包含一个“item”的基本信息（user.id、name、description、feature_1(bool)、feature_2(bool) ..等）
Feature_1：其中包含“项目”的一些可选值，因此如果用户决定将特征 1 用于他的项目，我们将在 Feature_1 中创建一条记录并填写这些值。 1 个项目在“Feature_1”表中不能有超过一条记录，因此它要么有 1 条记录，要么没有。
Feature_2：与 Feature_1 相同，但具有不同的可选值，因此用户可以将 Feature_1 添加到他的 Item 和/或 Feature_2。同样，每个项目可以有 0 或 1 个 Feature_2 记录。

我不确定这是否是最佳做法，其中一个选项是将 1 个表“项目”中的所有值与许多 NULL 值混合。

任何建议和指点将不胜感激。

【问题讨论】：

Google for EAV 数据库模型。
@N.B. - EAV 不是灵丹妙药。事实上，如果存在任何其他合适的解决方案，我会争辩不要使用它。也就是说，值得谷歌搜索和理解。无论如何，这不是一个普遍的答案。
@Dems - 没有什么是魔锤，但了解 EAV 是什么有助于决定使用什么方法/模型来解决特定问题。
@N.B. - 同意，但您的评论形式表明这是对 this 问题的答案。我不同意。
@Dems - 这就是我发表评论而不是答案的原因:)

标签： mysql sql database database-design

【解决方案1】：

分离出这样的值有助于处理锁定问题。如果您有多个正在运行的守护程序/脚本正在更新，并且这些表并在它们上持有锁，那么将所有这些值一起保存在一个表上可能是一个问题。当然，既然“项目”的值被分成三个表，那么如果/当你需要所有这些值时，你就会遇到追赶它们的问题。一般来说，将这些表像这样拆分是可以的。

另外，在任何人走上这样拆分数据的道路之前，通常最好尝试/用尽以下各项：

尽可能使用“with (nolock)”以防止出现锁定问题。

修改维护此数据的脚本以尽可能少地使用“begin tran”类型的事务。

修改维护数据的脚本的执行，使它们更有可能被顺序调用而不是并发调用。例如让他们从事相同的工作。

【讨论】：

【解决方案2】：

我倾向于同意这三个表。因为您说项目只能链接到零个或一个 Feature_1 和零个或一个 Feature_2，所以您可以使用对 Feature_1 和 Feature_2 主键的引用将两列添加到项目表中。您可以在这些列上使用外键约束并使它们可以为空以指示该功能不存在。这也意味着您可以删除布尔值并保留检查类型 1 或 2 功能是否可用而无需连接表的好处。

【讨论】：

【解决方案3】：

纯粹主义者会说您应该将每个功能作为单独的表，每个表都有一个指向 Items 表的外键。而且，一般来说，我同意，尽管如果相当少比例的项目不会同时具有这两个特征，并且特征记录的大小很小，那么消除必须加入表的开销可能是值得的。

【讨论】：

【解决方案4】：

对于这些类型的问题，没有一种万能的解决方案。但是您已经描述了两种非常常见且合适的解决方案。

理论上，您实际上可以从主表中删除 feature_x 布尔字段。该“事实”隐含在特征表中记录的存在或不存在中。拥有它们还不错，它是一种缓存/非规范化，会增加复杂性以潜在地提高性能。

我唯一可能避免这种设置的情况是用户可以创建新功能，或者您拥有大量不可行的功能。然后你可能想要一个实体-属性-值设置。 EAV 非常灵活，但也有其自身的重大问题。同样，没有一种适合所有人的方式。

简而言之，如果你所拥有的对你有用，那么你所拥有的似乎还不错。

【讨论】：