我有一位同事正在为一个新应用程序规划一个数据库，该应用程序将包含多个表，每个表包含 30 多个字段。这过分吗？也许我只是不够进取，无法理解。
编辑：此外，很多字段都是选项类型的东西（比如在请求表单上，您希望您的小部件是黄色还是绿色，他有一个带有枚举的“颜色”字段）。随着时间的推移，这些很可能会被添加或删除。我还没有真正做过数据库设计，并试图自己远离它，所以也许我完全是愚蠢的，但肯定有更好的方法吗？？
【问题讨论】：
标签： database database-design database-normalization
没有任意限制；足以完成工作是一个很好的经验法则
如果你有更好的数据库设计，建议
如果您需要更详细的反馈，请发布架构
【讨论】：
当然，标准答案是视情况而定。在某些情况下，包含这么多字段的表格实际上可能很有意义。
考虑一下您将在其中存储的数据。这些字段中的许多字段是否可能为 NULL？这些字段发生变化的可能性有多大（例如：添加更多）？
如果只有某些字段适用于某些对象，不妨考虑将这些字段放入另一个表中。或者，在一个表中只存储基本的通用字段，在另一个表中存储额外信息，每个字段一行。如I suggested 为a different question (which might be helpful to you)：
refs (id, title, refType) -- 引用的标题，以及它是什么类型的引用 fieldDef (id, fieldName, refType, dataType) -- 字段的名称，它适用于哪些引用类型，以及 -- 这些字段中存储了哪些类型的数据（ISDN 号码、日期等） 字段（refId、fieldId、值） -- 您实际将数据添加到引用的位置。请注意，这是 否决，并且可能有充分的理由。这是一种选择，不一定是最好的选择，但它仍然是一种可行的方法。然而，在我链接到的问题中，投票率最高的答案可能是最好的解决方案。
编辑：既然您说它将保存诸如每个用户设置之类的东西（例如：小部件颜色），我实际上会推荐上面概述的方法（使用三个表）。大多数人很有可能会保留默认设置，因此您将存储一堆无用的信息。请务必阅读我在另一个问题中的回答，因为其他读者已经指出了这种方法的缺点。
【讨论】：
字段的数量通常不是问题，但您要确保您的数据库正确规范化。 Third normal form 是一个好的开始。
【讨论】：
如果你不得不问，“这个表中的字段是不是太多了？”那么大概有。
【讨论】：
一个告示牌就是你所说的。他的字段理论上应该拆分到不同的表中。另一个好处是存在许多可选字段。
我会说数据库设计课程是为了您的数据库“专家”。我建议你也复习一下……它只会帮助你在职业生涯中成长:)
【讨论】：
数据库表中可以合法地包含 30 个或更多字段。您需要查看的是数据的规范化以及该规范化是否有意义。它通常也会在未来发生变化。但是，您想尽量减少这种情况。
例如，如果您有一个包含地址的表格，您是否在该表格中包含城市、州和邮政编码字段？或者，您是否只包含一个字段“指向”这些值的单独表中的记录？单独的表将包含唯一的城市、州、邮政编码组合。将数据拆分为两个表的效果是减少了存储的数据量（很可能但不是绝对的），但是当您对数据库运行查询时会增加一些复杂性。现在，您必须处理 2 张桌子，而不仅仅是一张。但是，从好的方面来说，它更干净，更小（可能）。
真正的答案是在适当的情况下将 city-state-zip 数据留在地址表中是可以的。或者，您可能希望将其“标准化”。两个都好。
如果在预算范围内，请找一位优秀的数据库管理员并在短期内雇用他们来审核计划。从长远来看，它会得到回报。
【讨论】：
三十个字段并不算多 - 您只需确保您的数据正确规范化（网络上有大量指南）。
根据您在其中指定许多列将是选项类型字段的编辑，这些字段可能会随着时间的推移而添加或删除，我建议以下是一个更好的主意。
BaseTable:
Id
NonOptionFields
OptionTable:
Id
OptionName
OptionValue
然后您可以将所有选项与基本记录联系起来。这意味着您不必一直以标准化的方式向表中添加和删除列来实现您想要的。
【讨论】：
我见过的表格需要规范化的最明显标志是以整数结尾的字段：CouponCode1、CouponCode2、CouponCode3.. 你明白了。不过，规则也会有例外。
【讨论】：
游击队默认规范化指南：
【讨论】：
数据库理论中对字段数量没有限制。一个表可以被限制为一个主键（即使这个主键由2个字段组成），这意味着Apocalisp's answer不是很清楚。相反，只要尊重normal form rules，就可以由数千个字段组成一个表格。
当表中的字段组明显未充分使用时，可以明智地将这组字段拆分到另一个表中，主表和“子”表之间的关系为 0-1。
出于安全原因，也经常提出（很久以前：我认为这是我的第一本关系数据库书籍，首次出版于 197 年？）将机密信息拆分到另一个具有相同 0-1 关系的表中主要和次要之间。然后可以轻松地限制用户对“子”表的访问。现在可以通过视图轻松管理这样的配置。
【讨论】：
“太多”这个词是相对的...您不应该仅仅为了减少字段数量而拆分表，尤其是在每个查询中您都必须将它们重新连接在一起的情况下因为它们本质上是一对一的关系。如果可以将字段分解为一个单独的逻辑对象，那么这将是有意义的。例如，不是将地址字段存储在客户表中，而是可以将它们移动到单独的地址表中。这是一个粗略的例子，但它说明了我的观点。
【讨论】：
OLTP
根据我设计数据库的经验，规范化的 OLTP 数据库中很少有表包含大量的列。
IMO 30 列太多了。
对我来说，不超过 10% 的 OLTP 表有大量 (>10) 列。
OLAP
现在，如果您要创建维度/报告结构，有些人可能会认为 30 列的表很窄。
【讨论】：