表中有多少字段"太多"？

我有一个同事正在计划一个新应用程序的数据库,该应用程序将包含多个表,每个表包含30多个字段.这太过分吗？也许我只是不够了解企业.

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

1> JR Lawhorne..：

---

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

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

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

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

---

如果每个地址可以多次使用,则将地址拆分为单独的表是有意义的,但除非您使接口复杂化,否则这种情况不太可能.如果每个地址仅由一个人使用,那么您所做的是垂直分区,而不是标准化.

2> Chris Missal..：

---

表格中最明显的标志是我看到的标准化是以整数结尾的字段:CouponCode1,CouponCode2,CouponCode3 ..你明白了.尽管如此,规则也会有例外.

---

我的一位同事总是说"数据库的拇指规则 - 总是打倒!"

3> paxdiablo..：

---

三十个字段不是太多 - 您只需要确保您的数据正确标准化(网上有大量指南).

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

BaseTable:
    Id
    NonOptionFields
OptionTable:
    Id
    OptionName
    OptionValue

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

4> nickf..：

---

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

考虑一下你将要存储的数据.是否很可能这些字段中的许多都是NULL？这些字段发生变化的可能性是多少(例如:添加更多字段)？

如果只有某些字段适用于某些对象,也许可以考虑将这些字段放入另一个表中.或者,只在一个表中存储基本的公共字段,在另一个表中存储额外信息,每个字段一行.至于我提出了一个不同的问题(这可能对您有所帮助):

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.

请注意,这是低估的,可能有充分的理由.这是一个选项,不一定是最好的选择,但它仍然是一个可行的方法.然而,在与我联系的问题中,最高投票答案可能是最好的解决方案.

---

编辑:因为你说它将持有像每个用户设置(例如:小部件颜色)的东西,我实际上推荐上面概述的方法(使用三个表).有可能大多数人会将内容保留为默认值,因此您将存储一堆无用的信息.请在其他问题中阅读我的答案,因为其他读者已经指出了这种方法的缺点.