我是使用SQL Server 2012构建运营数据存储（ODS）数据库的团队的一员，我们的一些分析师将使用它来进行预测建模。 ODS将包含我们制造的单一产品的制造生产数据。
我们将在ODS中拥有数百个表格。但是，我们将有一个核心表，其中包含有关每个制造项目的关键信息（生命周期信息）（每年数千万）。我们的产品在一家制造工厂生产，并且在生产线上花费大约2.5小时的时间进行各种工艺。我们希望在这个核心表中存储各种各样的，制造的和制造后的信息。一个示例数据可能是产品进入特定烤箱的时间。
我们决定如何构建此表。我们可以创建一个宽表（多列）或一个窄表，其中大多数列是行（作为属性值）。我从来没有设计和使用非常窄的表结构，并且列被视为表中的行。
我想要一些广泛的桌子与狭窄的桌子的利弊反馈。以下内容可能有助于此讨论：
每年生产的产品数量：数百万（每个产品实例将在核心表中排成一行）
经常会查询此表：是的，经常查询。它将是许多子表的父级。
可能的列数（或行属性）：75到150 +
如果有更多信息有用，我很乐意提供。
答案 0 :(得分：5)
宽表，静态属性
您正在通过明确定义的制造流程跟踪单个产品。这个数据模型听起来非常静态，并且可以扩展到一个包含许多列的宽表中，这些列一直填充数据。
窄表，动态属性
如果您有许多产品在制造过程中有很多变化，那么它将更适合于狭窄的工作台，您可以在其中轻松添加新属性以进行跟踪。
难以查询窄表
然而，即使简单查询窄表也非常困难。例如，当该属性在100多个其他属性行中混洗时，如果需要按特定属性对数据进行排序，该怎么办？如何将所有行组合在一起形成一个“记录”，然后对结果集中的记录组进行排序？
更易于查询的平面表
根据您查看和分析数据的方式，您可能会发现自己经常使用数据透视表或交叉表查询。如果是这种情况，那么为什么不先将存储表弄平呢？
或两者兼顾
另一个选择是同时执行这两项操作：以窄范围存储数据，并使用转换过程将其展平以便于报告。这样您就可以快速开始跟踪新属性（只需添加行），然后您可以更新报告表并更新转换过程以利用新数据。
答案 1 :(得分：0)
宽度有多宽？嗯，宽表可能有几个问题。
一个问题是宽表往往偏离规范化数据的规则。这反过来会导致棘手的更新问题，您必须小心防止数据库进入自相矛盾的状态。这里的宽度有多宽，没有特别的答案。只需应用规范化规则，您最终将分解表格。
但是，有些数据库并非以规范化为指导原则。特别是，考虑星型模式中的事实表。有些时候某些部分是由FK的某个子集决定的，这可能会违反3NF甚至2NF。在明星模式中保持事实表变薄仍然很重要，但这是出于不同的原因，即速度。有时，通过将数据推送到其中一个维度表，可以使事实表更加简洁。有时，您可以将恒星分解为两个或更多相关恒星。
您的情况听起来像上面给出的第二个原因，即使您的设计可能不是星型模式。不过，星型模式设计原则可能会帮助您改进设计。