为什么一张桌子上有太多的气味？

Question

最近，我与其他一些开发人员讨论了表中列数太多，或者模型中的属性太多是代码味道。有人认为具有太多属性的模型做了太多事情，应该拆分。 但是，如果模型实际需要这些属性呢？

让我举一个users表的例子。

用户可以拥有 first_name，last_name，street_name，city，state，age等。 根据这个论点，我认为应该将street_name，city和state移到另一个表中。我同意相关数据以这种方式组合在一起，但是如果应用程序也在用他的地址查询用户，那么这不是一个更昂贵的操作，因为他们现在在2个表中？

那么对具有大量属性的表进行建模的正确方法是什么？ （我们是否也应该考虑这些情况：何时  1.行数将减少  2.行数将是巨大的）

Answer 1

这不是“一张桌子中的属性太多”的问题。这是一个“在一个表中将错误的属性绑定在一起”的问题。表格的关键应该与主题中的某个实体或关系相关。非关键属性应该取决于（由...确定）密钥，整个密钥，以及除密钥之外的其他任何内容。

这是所谓的“数据规范化”的简化视图。数据规范化有助于防止在数据库中的多个位置存储相同事实的必要性。这种有害的冗余不仅浪费，而且还会导致数据库与自身相矛盾。这真是一种痛苦。

将非标准化设计转换为标准化设计通常涉及拆分表。但不要随意拆分表。学习规范化规则。跟着他们，直到你成为专家，知道什么时候忽视它们。

Answer 2

这是一个非常具有学术性的问题。在设计数据库模型时，通常只考虑一件事：性能。你不会因为它看起来更好而拆分表。你会这样做

• 何时可以减少冗余
• 或增强并发性。

当不是所有数据库时，对大多数记录的限制也存在限制。因此，您可以拆分表以使数据库能够有效地存储它。

设计课程时完全不同。拆分类不会对性能产生很大影响，但会对维护产生很大影响。可维护性应该是主要关注点。

Answer 3

具体使用您的address方案，如果您的设计应该满足每个用户的多个地址或使用相同的地址跟踪/捕获多个注册，您会发现它非常有用。

或者，您可以考虑更通用的地址表实现，其中您具有通用description字段和type列，该行将该行标记为特定类型的地址（例如email ，house，office，spouse等。）

故事的寓意是这个故事的寓意是，如果有不止一个，有一个单独的表。过度归一化只会在跳过额外的一两个表没有任何好处时才会出现以下信息：

1. 变化不大，
2. 不会出现多次或
3. 每个主要密钥实体都必须拥有它。