对于具有相同数据属性的三个独立对象，一个表还是三个？答案

【问题标题】：One Table Or Three For Three Separate Objects That Have Identical Data Attributes?对于具有相同数据属性的三个独立对象，一个表还是三个？
【发布时间】：2010-12-25 02:52:49
【问题描述】：

我正在为一本杂志建立一个网站，其中包括三个不同的部分——文章、博客文章和评论。所有这三种对象类型都有以下共同的列：标题、描述、标题、副标题、正文和作者。我应该将它们分别存储在自己的表中，还是应该只创建一个 Posts 表并添加一个类别，以便区分 ['article','blog','review']？

要明确一点——这三者中的每一个都将以完全不同的视觉格式呈现给用户，因此它不像只是一个带有文章、博客和评论的类别或标签的博客。但是应该在幕后这样吗？

很难决定是否应该仅根据它们实际上是独立的对象这一事实来拆分它们，还是将它们全部放在一起以保持我的应用程序 DRY。这会导致后续的维护问题吗？性能问题？正常化？数据的完整性？我不是数据库专家，因此非常感谢任何帮助。

我认为这根本不重要，但我使用的是 Rails，所以我想弄清楚我是否最终会得到 3 个不同的控制器、3 个模型和 12 个视图，我如果背后有充分的理由，我们很乐意这样做。

提前致谢！

【问题讨论】：

感谢所有回复的人，非常感谢您的建议。

标签： mysql ruby-on-rails database database-design data-modeling

【解决方案1】：

我建议添加一列来指示类型。如果您将其称为 type 这将允许您移动到单表继承 (also here)，即使模型开始略有分歧。然后你会得到......

class Post < ActiveRecord::Base
class Article < Post
class Blog < Post
class Review < Post

在大多数情况下，您可以使用 Post 和单个 Controller，然后使用继承来处理特殊行为，例如验证。

【讨论】：

【解决方案2】：

如果它们之间的属性相同，则没有理由使用单独的表。

其中两个对象可能具有相同的属性，因此在这种情况下您将创建两个表。

【讨论】：

【解决方案3】：

一个表添加类别字段。

只要您确定此模型不会更改并且实体相似，那么您将需要一个带有附加字段 TypeID 的表。然后，当您想显示仅包含博客文章的网格时，您只需添加 WHERE 条件 WHERE TypeID='blog posts'

【讨论】：

【解决方案4】：

将外键添加到单独的类型表中可以很容易地在新类别出现时添加它们。如果行为不是基于类型的不同，我会推荐它超过三个单独的对象。

【讨论】：

【解决方案5】：

如果证明有必要，以后拆分表格要比合并可能同时添加了单独字段的表格要容易得多，如果您一开始是分开的。我将从统一的方法开始。

【讨论】：

【解决方案6】：

使用 3 个不同的表格，因为这三个表格的性质/行为都不同一定要尽量避免冗余，但我不认为在这种情况下它是冗余。

使用单独表格的原因：

1) 很可能您很快就会为这些表中的每一个添加更多列，并且每个表的列都会有所不同。如果您现在使用一张桌子，那么您将把它们都放在一张桌子上，这会造成混乱。

2) 如果表快速增长，速度、锁、大小等方面的问题就会减少。

另外，现在担心还为时过早.. 把它写完.. 一个月后重构它！！

【讨论】：

我们可能会在一个月内倒闭！哈哈！但说真的，你在这里的原因正是我不知道该怎么做的确切原因。感谢您的回答！

【解决方案7】：

一张表，也看问题/答案to use sub-type or not；非常相似。

【讨论】：

是的，我完全看到了那个。这绝对是我能找到的最接近这个问题的匹配。谢谢大佬。

【解决方案8】：

我的问题是你打算如何查询他们？您是否需要同时获取所有三种类型的信息？如果您需要所有三种类型的数据，则单个表将更易于设计查询。如果需要，您可以将所有常见字段放在一个表中，稍后添加专用表以获取所有三个不通用的信息，或者如果它不会使表太宽，则为此信息添加可空字段。如果它们永远不会一起被查询，那么这三个表可能是一个更好的主意，因为它可以让您更灵活地更改一个表的结构。

【讨论】：

唯一一次我需要同时查询所有这些是当用户正在搜索某物时。如果他们搜索，我希望文章、评论和帖子显示在同一组搜索结果中。

【解决方案9】：

这是一个称为“泛化-专业化”的模式示例。

从面向对象的角度来看，对对象模型的任何处理都将涵盖 gen-spec。从关系的角度获得良好的治疗有点困难。

如果您在 Google 上搜索“泛化专业化关系建模”，您会得到几篇关于这个主题的好文章。我不能确切地说出在您的情况下最好的设计是什么，但我怀疑这将类似于拥有一个具有所有常见属性的表，并为每个专业项目单独的表。专用表不需要单独的 id 列。只需引用每个专用表中的公共 id 字段，并将此 FK 也作为自己表的 PK。

我指向的文章将为这种设计提供更完整的理由。 YMMV。

【讨论】：