Question

我有一位同事正在为一个新应用规划数据库，该应用将包含多个表，每个表包含30多个字段。这太过分吗？也许我只是不够了解企业。

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

Answer 1

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

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

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

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

Answer 2

表中需要规范化的最明显的标志是我看到的是以整数结尾的字段：CouponCode1，CouponCode2，CouponCode3 ..你明白了。不过，规则会有例外情况。

Answer 3

30个字段不是太多 - 您只需要确保您的数据已正确规范化（网上有大量指南）。

根据您的编辑，您指定许多列将是可随时间添加或删除的选项类型字段，我建议以下是更好的主意。

BaseTable:
    Id
    NonOptionFields
OptionTable:
    Id
    OptionName
    OptionValue

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

Answer 4

当然，标准答案是取决于。在某些情况下，包含许多字段的表实际上可能非常有意义。

考虑一下你将要存储的数据。是否很可能这些字段中的许多都是NULL？这些字段发生变化的可能性有多大（例如：添加更多字段）？

如果只有某些字段适用于某些对象，或许可以考虑将这些字段放入另一个表中。或者，只在一个表中存储基本的公共字段，在另一个表中存储额外信息，每个字段一行。作为I suggested的a different question (which might be helpful to you)：

refs (id, title, refType)
-- title of the reference, and what type of reference it is

fieldDef (id, fieldName, refType, dataType)
-- name of the field, which reference types it applies to, and
-- what type of data is stored in these fields (ISDN number, date, etc)

fields (refId, fieldId, value)
-- where you actually add data to the references.

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

字段数通常不是问题，但您要确保数据库正确无误。 Third normal form是一个好的开始。

Answer 8

<强> OLTP

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

IMO 30列太多了。

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

<强> OLAP

现在，如果你要进行维度/报告结构，有些人可能会考虑将30列表缩小。

Answer 9

如果你不得不问，“这张桌子上的字段太多了吗？”然后可能有。

Answer 10

游击队的标准化指南 - 默认情况下：

一个表应该有一个主键，最多只有一个列。
仅根据需要经常违反规则第1号。

Answer 11

数据库理论中的字段数没有限制。表可以限制为主键（即使此主键由2个字段组成），这意味着Apocalisp's answer不是很清楚。在对立面上，只要尊重normal form rules，就可以从字段的表格中制作表格。

当表中的字段组明显不足时，将这组字段拆分到主表和“子”表之间的0-1关系的另一个表中是明智的。

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

Answer 12

告诉标志就是你所说的。他的领域理论上应该分成不同的表格。另一个赠品是存在许多可选字段。

我会说数据库设计课程是为了你的数据库“专家”。而且我建议你也刷它......它只会帮助你在你的职业生涯中成长：）

表中有多少字段“太多”？

12 个答案: