23

我有一位同事正在为一个新应用程序计划一个数据库，该应用程序将有几个表，每个表都有超过 30 个字段。这过分吗？也许我只是不够进取，无法理解。

编辑：另外，很多字段都是选项类型的东西（比如在请求表上，你希望你的小部件是黄色还是绿色，他有一个带有枚举的“颜色”字段）。随着时间的推移，这些很可能会被添加或删除。我还没有真正完成数据库设计并试图自己远离它，所以也许我完全是愚蠢的，但肯定有更好的方法来做到这一点？

4

12 回答 12

13

我见过的表格需要规范化的最明显标志是以整数结尾的字段：CouponCode1、CouponCode2、CouponCode3.. 你明白了。一如既往，规则会有例外。

于 2008-10-21T03:46:57.647 回答
12

数据库表中可以合法地包含 30 个或更多字段。您需要查看的是数据的规范化以及该规范化是否有意义。它通常也会在未来发生变化。但是，你想尽量减少它。

例如，如果您有一个包含地址的表，您是否在该表中包含城市、州和邮政编码字段？或者，您是否只包含一个字段“指向”这些值的单独表中的记录？单独的表将包含唯一的城市、州、邮政编码组合。将数据分成两个表的效果是减少了存储的数据量（很可能但不是绝对的），但是当您对数据库运行查询时会增加一些复杂性。现在，您必须处理 2 张桌子，而不仅仅是一张。但是，从好的方面来说，它更干净，更小（可能）。

真正的答案是在适当的情况下将 city-state-zip 数据留在地址表中是可以的。或者，您可能希望将其“标准化”。两者都很好。

找一个优秀的数据库管理员并在短期内雇用他们来审查计划，如果它在预算之内。从长远来看，它会得到回报。

于 2008-10-21T03:14:50.597 回答
8

三十个字段并不算多——你只需要确保你的数据被正确规范化（网上有很多指南）。

根据您在其中指定许多列将是随着时间的推移可能会添加或删除的选项类型字段的编辑，我建议以下是一个更好的主意。

BaseTable:
    Id
    NonOptionFields
OptionTable:
    Id
    OptionName
    OptionValue

然后，您可以将所有选项与基本记录联系起来。这意味着您不必一直以标准化的方式在表中添加和删除列来实现您想要的。

于 2008-10-21T03:28:55.060 回答
7

当然，标准答案是视情况而定。在某些情况下，具有这么多字段的表实际上可能很有意义。

想想你将在那里存储的数据。这些字段中的许多字段是否可能为 NULL？这些字段发生变化的可能性有多大（例如：添加更多）？

如果只有某些字段适用于某些对象，或许可以考虑将这些字段放入另一个表中。或者，在一个表中只存储基本的通用字段，在另一个表中存储额外信息，每个字段一行。正如我建议的一个不同的问题（这可能对你有帮助）：

refs (id, title, refType)
-- 引用的标题，以及它是什么类型的引用

fieldDef (id, fieldName, refType, dataType)
-- 字段的名称，它适用于哪些引用类型，以及
-- 这些字段中存储了哪些类型的数据（ISDN 号码、日期等）

字段（refId、fieldId、值）
-- 您实际将数据添加到引用的位置。

请注意，这被否决了，并且可能有充分的理由。这是一个选项，不一定是最佳选项，但它仍然是一种可行的方法。然而，在我链接到的问题中投票最高的答案可能是最好的解决方案。

编辑：既然您说它将包含每个用户设置之类的东西（例如：小部件颜色），我实际上会推荐上面概述的方法（使用三个表）。大多数人很有可能会保留默认设置，因此您将存储一堆无用的信息。请务必阅读我在另一个问题中的回答，因为其他读者已经指出了这种方法的缺点。

于 2008-10-21T03:03:34.177 回答
4

术语“太多”是一个相对的......你不应该仅仅为了减少字段数量而拆分表，特别是如果在每个查询中你必须将它们重新连接在一起，因为它们是本质上是一对一的关系。如果可以将字段分解为一个单独的逻辑对象，那么这将是有意义的。例如，不是将地址字段存储在客户表中，而是可以将它们移动到单独的地址表中。这是一个粗略的例子，但它说明了我的观点。

于 2008-11-14T15:39:15.030 回答
4

没有任意限制；足以完成工作是一个很好的经验法则

如果你有更好的数据库设计，建议

如果您需要更详细的反馈，请发布架构

于 2008-10-21T03:02:43.617 回答
3

OLTP

根据我设计数据库的经验，规范化的 OLTP 数据库中很少有表包含大量的列。

IMO 30 列太多。

对我来说，不超过 10% 的 OLTP 表有大量（>10）列。

OLAP

现在，如果您要创建维度/报告结构，有些人可能会认为 30 列的表很窄。

于 2009-07-22T13:44:21.693 回答
3

字段的数量通常不是问题，但您要确保您的数据库正确规范化。 第三范式是一个好的开始。

于 2008-10-21T03:05:51.193 回答
2

如果非要问，“这张表的字段是不是太多了？” 然后大概有。

于 2008-10-21T03:10:10.170 回答
1

数据库理论中对字段数量没有限制。一个表可以限制为一个主键（即使这个主键是由2个字段组成的），这意味着Apocalisp的回答不是很清楚。相反，只要遵守范式规则，表格就可以由数以千计的字段组成。

当表中的字段组明显未充分使用时，可以明智地将这组字段拆分到另一个表中，主表和“子”表之间的关系为 0-1。

出于安全原因，也经常有人提议（很久以前：我认为这是我的第一本关系数据库书，首次出版于 197 年？）将机密信息拆分到另一个表中，主和之间具有相同的 0-1 关系子。然后可以轻松地限制用户访问“子”表。现在可以通过视图轻松管理这样的配置。

于 2008-10-21T12:10:09.470 回答
1

游击队默认规范化指南：

  1. 一个表应该有一个主键和最多一个其他列。
  2. 仅根据需要频繁地打破第 1 条规则。
于 2008-10-21T03:59:22.393 回答
0

一个告示牌就是你所说的。他的字段理论上应该拆分到不同的表中。另一个赠品是存在许多可选字段。

我想说数据库设计课程是为了您的数据库“专家”。我建议你也复习一下……它只会帮助你在职业生涯中成长:)

于 2008-10-21T03:12:46.530 回答