我必须创建一个数据库来存储向第三方Web服务门户发送和接收的信息。虽然我可以通过规范化删除大约50个字段，但是有大约150个字段要发送的信息（例如，有三组地址可以保存在地址表中）。但是，这仍然会留下一个可能有100列的表。
虽然我不确定使用哪种方法，但我想出了两种方法：
1 即可。有一个包含100列的表和三个对地址表的引用。
2 即可。将其细分为15-20个独立的专用表格。
选项1 似乎最快，因为它涉及最少的连接但是有100列的表的想法感觉不对。
选项2 感觉更好，并且会将内容分解为更多可管理的块，但它不会保存任何数据库空间并且会增加连接数。几乎所有数据库中的列都有一个值，我无法再对这些列进行标准化。
我的问题是，在这种情况下，是否可以使用包含c.100列的表，或者我应该尝试将其分解为几个表以进行演示？
请注意：表格结构在使用过程中不会改变，将为新版本的Web服务门户创建新数据库。我无法控制Web服务数据结构。
编辑： @ Oded的回答让我更多地考虑如何访问数据;它实际上只能被访问，而不是部分访问。例如，我不需要定期返回第5-20列。
答案：我在发布后根据评论接受了Oded的答案，帮助我解决了问题，我决定选择1。因为数据是全部访问然后有一个表似乎是更好的解决方案例如，如果我经常想要访问第5-20列而不是完整的表行，那么出于性能原因，我会看到将其分解为单独的表。
答案 0 :(得分：10)
从关系纯粹主义的观点来看 - 首先，如果它们是相关的，那么表中没有任何列可以反对。这里的要点是，如果normalizing之后你还有100列，那就没关系。
但是你应该规范化，并且在这个过程中你最终会得到15-20个独立的专用表，大多数关系数据库专业人员会同意这是一个更好的设计（避免数据重复与更新/删除相关问题，缩小数据占用空间等......）。
然而，实际上，如果存在可测量的性能问题，非规范化您的设计以获得性能优势可能是明智的。关键在于 - 可测量。在遇到实际问题之前不要进行优化。在这方面，我会说你应该把15-20张表作为初步设计。
答案 1 :(得分：3)
来自MSDN：Maximum Capacity Specifications for SQL Server：
每个非扩展表的列数：1,024
每张宽表的列数：30,000
所以我认为在你的情况下100列是可以的。也许你需要注意（来自同一个链接）：
每个主键的列数：16
当然，只有在需要数据仅作为服务的日志时才会出现这种情况。
如果在阅读服务后您需要维护数据 - ＆gt;然后正常化似乎更好......
答案 2 :(得分：1)
如果您发现使用较少的列“管理”表更容易，但是您恰好定义了可管理性（例如，在查看SSMS中的表数据时减少水平滚动），您可以将表分成几个表与1对1的关系而不违反规范化规则。