SQL Server：一个包含400列的表或包含10列的40个表？

Question

我正在使用SQL Server 2005 Express和Visual Studio 2008.

我有一个数据库，其中有一个包含400列的表。在我必须在几个数据库之间执行双向同步之前，事情（几乎可以管理）。

我想知道使用400列数据库或40个表数据库的参数和反对是什么？

未规范化的表，主要由nvarchar（64）列和一些TEXT列组成。 （没有从文本文件转换的数据类型）。

还有一个表链接到此表并且是1-1关系（即一个条目与400列表中的一个条目相关）。

该表是一个列表文件，其中包含“插入”应用程序的参数。

我期待你的回复。

谢谢

Answer 1

有一张宽桌子：

• 快速报告，因为它可能是非规范化的，因此不需要加入。
• 最终消费者易于理解，因为他们不需要掌握数据模型。

反对宽表：

• 可能需要多个复合索引才能获得良好的查询性能
• 更难以维护数据一致性，即如果数据在多行上，则需要在数据更改时更新多行
• 由于您需要更新多行并维护多个索引，因此当锁升级时，更新的并发性能可能会成为一个问题。
• 如果该属性与该行上的实体无关，可能会使处理结果变得尴尬，那么您最终可能会在列中显示带有空值的记录。
• 如果懒惰的开发人员从表中执行SELECT *，您最终会在网络中拖动大量数据，因此您通常必须维护合适的子集视图。

所以这一切都取决于你在做什么。如果表的主要目的是OLAP报告并且更新很少并且影响很少的行，则可能是一个宽的，非规范化的表是正确的。在OLTP环境中，它可能不是，你应该更喜欢更窄的表。 （我通常在3NF中进行设计，然后在我进行时对查询性能进行非规范化。）

如果这是他们想要看到的内容，您可以随时采用规范化的方法并为读者提供广阔的视野。

如果不了解情况，就不可能在特定情况下更多地说明利弊。

修改

鉴于你在评论中所说的话，你是否考虑过长篇大论？瘦名称=值对表，所以你只有UserId，PropertyName，PropertyValue列？您可能还想在其中添加一些其他元属性;时间戳，版本或其他。 SQL Server在处理这些类型的表时非常有效，所以不要忽视像这样的简单解决方案。

Answer 2

根据您的流程描述，我会从这样的事情开始。模型简化，不捕获历史等 - 但它是一个很好的起点。注意：参数=属性。

- 设置是属性的集合。一个设置可以包含多个属性，一个属性仅属于一个设置。
- 计算机可以有多个设置，一个设置仅属于一个计算机。
- 属性具有特定的类型（温度，运行时间，主轴速度），可以有许多属性的类型即可。
- 度量和特性是属性的类型。 衡量是一种数字属性，就像速度一样。 特质是一种描述性属性，如颜色或某些文字。