什么是更好的数据库设计:更多表或更多列？

Question

一位前同事坚持认为,每个数据库中包含更多列的表更少,每个表更少的表更少.例如,而不是具有名称,地址,城市,州,邮政等列的客户表,您将拥有名称表,地址表,城市表等.

他认为这种设计更有效,更灵活.也许它更灵活,但我没有资格对其效率发表评论.即使效率更高,我认为增加的复杂性可能会超过这些收益.

那么,对于包含更少列的更少列的更少列,是否有任何显着优势？

Answer 1

我在设计数据库时遵循一些相当简单的经验法则,我认为可以用来帮助做出像这样的决定....

1. 赞成规范化.非规范化是一种优化形式,具有所有必要的权衡,因此应以YAGNI态度来处理.
2. 确保引用数据库的客户端代码与模式分离得足够复杂,重新设计它不需要对客户端进行重大的重新设计.
3. 当它为性能或查询复杂性提供明显的好处时,不要害怕反规范化.
4. 当数据量和使用方案允许时,使用视图或下游表来实现非规范化,而不是对模式的核心进行非规范化.

这些规则的通常结果是初始设计将有利于表而不是列,重点是消除冗余.随着项目的进展和非规范化点的确定,整体结构将朝着平衡方向发展,这种平衡会牺牲冗余和列扩散,以换取其他有价值的好处.

Answer 2

它听起来不像关于表/列的问题,而是关于规范化.在某些情况下,高度标准化(在这种情况下"更多表格")是好的,干净的,但通常需要大量的JOIN来获得相关结果.如果数据集足够大,可能会降低性能.

杰夫写了一些关于StackOverflow设计的文章.另见Dare Obasanjo发布的Jeff链接.

Answer 3

我会支持更多的表格,但只能达到某一点.使用您的示例,如果您将用户的信息分成两个表,例如USERS和ADDRESS,这使您可以灵活地为每个用户分配多个地址.一个明显的应用是具有单独的计费和送货地址的用户.

支持拥有单独的CITY表的论点是,您只需存储一个城市的名称,然后在需要时参考它.这确实减少了重复,但在这个例子中我认为这是过度的.它可能更节省空间,但是当您从数据库中选择数据时,您将为连接付出代价.

Answer 4

这取决于您的数据库风格.例如,MS SQL Server倾向于选择较窄的表.这也是更"规范化"的方法.其他引擎可能更喜欢它.大型机往往属于该类别.

Answer 5

完全标准化的设计(即"更多表")更灵活,更易于维护,并避免数据重复,这意味着您的数据完整性将更容易实施.

这些是规范化的有力理由.我会先选择规范化,然后在看到性能成为一个问题后才对特定表进行非规范化.

我的经验是,在现实世界中,即使使用非常大的数据集,也不会达到非正规化的程度.

Answer 6

每个表应仅包含与由主键唯一标识的实体相关的列。如果数据库中的所有列都是同一实体的所有属性，那么您只需要一张包含所有列的表。

但是，如果任何列可能为空，则您需要将每个可为空的列放入其自己的表中，并使用主表的外键对其进行规范化。这是一个常见的场景，因此为了更简洁的设计，您可能需要向现有表添加比列更多的表。此外，通过将这些可选属性添加到它们自己的表中，它们将不再需要允许空值，并且您可以避免大量与 NULL 相关的问题。