0

最近，我与其他一些开发人员讨论了表格中有多少列，或者模型上有太多属性是代码异味。有人争辩说，拥有太多 Attribute 的 Model 做的事情太多，应该拆分。但是如果模型实际上需要这些属性呢？

让我以一张users桌子为例。

一个用户可以有 first_name, last_name, street_name, city, state, age, 等等。根据论证，我假设street_name，city并且state应该被移动到不同的表中。我同意以这种方式将相关数据分组在一起，但如果应用程序也在用他的地址查询用户，那会不会是一个更昂贵的操作，因为它们现在在 2 个表中？

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

4

3 回答 3

2

这不是“一张表中有太多属性”的问题。这是一个“将错误的属性绑定在一个表中”的问题。表的键应该与主题中的某些实体或关系相关。非关键属性应该依赖于（由）关键、整个关键以及除了关键之外什么都没有。

这是对所谓的“数据规范化”的过度简化的看法。数据规范化有助于避免在数据库的多个位置存储相同的事实。这种有害的冗余不仅浪费，而且还可能导致数据库自相矛盾。这是一个真正的痛苦。

将非规范化设计转换为规范化设计通常涉及拆分表。但不要只是随意拆分表格。学习规范化规则。跟随他们，直到你变得足够专业，知道什么时候可以无视他们。

于 2012-08-24T10:41:51.190 回答
1

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

  • 什么时候可以减少冗余
  • 或增强并发性。

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

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

于 2012-08-24T06:19:06.680 回答
1

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

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

这个故事的寓意是这个故事的寓意是如果它可能不止一个，有一个单独的表。过度规范化仅在跳过额外的一两个表格没有任何好处时才会出现：

  1. 变化不大，
  2. 不超过一次或
  3. 每个主键实体都必须拥有它。
于 2012-08-28T04:43:02.747 回答