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