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

Question

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

让我以users表为例。

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

那么什么是正确的方式来建模具有很多属性的表？ （如果我们也考虑这些情况：当 1的行数要少 2行的数量将是巨大的）

Answer 1

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

或者，你可以考虑一个更通用的地址表的实现，你有一个通用的description场和type列标签的行作为一个特定的地址类型（例如email，house，office，spouse等）。

故事的寓意是这个故事的寓意是如果可能有多于一个的话，就有一个单独的表。在规范化只设置时，有在跳跃的额外的表或两个信息没有好处就是：

1. 没有太大变化，
2. 不出现超过一次或
3. 每一个主键实体更多必须拥有它。

Answer 2

这是一个相当跑位问题。在设计数据库模型时，您经常只记住一件事：性能。你不会因为看起来更好而拆分表格。你会做到这一点，例如

• 的时候可以减少冗余
• 或提高并发性。

当不是所有的数据库时，大多数记录的大小也有限制。所以你可以拆分一张表来使数据库能够有效地存储它。

设计课程完全不同。分裂课程没有很大的性能影响，但是对维护有很大的影响。可维护性应该是主要关心的问题。

Answer 3

这不是“一张桌子上有太多属性”的问题。这是一个“在一张表中将错误的属性绑定在一起”的问题。表格的关键应与主题中的某个实体或关系相关。非关键属性应该取决于（由其确定）关键字，整个关键字以及关键字。

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

将非标准化设计转换为标准化设计通常需要拆分表格。但不要随意拆分表格。了解规范化规则。跟随他们，直到你成为足够专家，知道何时忽视他们。