数据库设计：一张大表与几张小表答案

【问题标题】：Database design: one large table versus several smaller tables数据库设计：一张大表与几张小表
【发布时间】：2013-05-31 10:55:59
【问题描述】：

我必须创建一个数据库来存储向/从第三方 Web 服务门户发送和接收的信息。大约有 150 个信息字段要发送，尽管我可以通过规范化删除其中大约 50 个字段（例如，可以将三组地址保存在地址表中）。但是，这仍然会留下一个可能有 100 列的表。

我想出了两种方法来处理这个问题，但我不确定使用哪种方法：

1。有一个包含 100 列和三个对地址表的引用的表。

2。将其分解为 15-20 个单独的专用表。

选项 1 似乎最快，因为它涉及的连接最少，但 100 列的表的想法感觉不对。

选项 2 感觉更好，并且会将事情分解成更易于管理的块，但它不会节省任何数据库空间并且会增加连接数。数据库中几乎所有的列都会有一个值，我无法进一步规范这些列。

我的问题是，在这种情况下，是否可以接受包含 c.100 列的表格，或者我应该尝试将其分解为多个表格以进行演示？

请注意： 表结构在使用过程中不会改变，将为新版本的 Web 服务门户创建一个新数据库。我无法控制 Web 服务数据结构。

编辑： @Oded 下面的回答让我对如何访问数据有了更多思考；它实际上只会被整体访问，而不是部分访问。例如，我不需要定期返回第 5-20 列。

回答： 在 Oded 发布后，我接受了基于 cmets 的回答，这帮助我下定了决心，我决定选择选项 1。因为数据是完整访问的，所以只有一张桌子似乎是更好的解决方案。例如，如果我经常想要访问第 5-20 列而不是整个表行，那么出于性能原因，我会看到将其分解为单独的表。

【问题讨论】：

【解决方案1】：

从关系纯粹主义者的角度讲 - 首先，如果表中有 100 列相关，则没有什么反对的。这里的重点是，如果在normalizing 之后你还有 100 列，那没关系。

但是您应该规范化，并且在此过程中您很可能会得到 15-20 个单独的专用表，大多数关系数据库专业人士都认为这是一个更好的设计（避免与更新/删除相关问题、更小的数据占用空间等...）。

然而，如果存在可衡量的性能问题，则务实地非规范化您的设计以提高性能可能是明智的。这里的关键 - 可测量的。在遇到实际问题之前不要进行优化。

在这方面，我认为您应该将 15-20 个表作为初始设计。

【讨论】：

【解决方案2】：

来自 MSDN：Maximum Capacity Specifications for SQL Server：

每个非宽表的列数：1,024

每个宽表的列数：30,000

所以我认为在你的情况下 100 列是可以的。而且也许你需要注意（来自同一个链接）：

每个主键的列数：16

当然，这只是在需要数据仅作为服务日志的情况下。

如果从服务读取后您需要维护数据 -> 那么规范化似乎更好...

【讨论】：

【解决方案3】：

如果您发现“管理”具有较少列的表格更容易，但您碰巧定义了可管理性（例如，在 SSMS 中查看表格数据时水平滚动较少），您可以将表格分成几个表格 在不违反规范化规则的情况下具有一对一的关系。

【讨论】：