我们刚刚开始设计一个新的数据仓库，我们正在尝试设计日期和时间维度的工作方式。我们需要能够支持多个时区（可能至少是 GMT、IST、PST 和 EST）。我们最初认为我们将有一个广泛的组合日期时间维度，大约 15 分钟的粒度，这样我们的事实表中有一个键，所有支持的时区的所有不同日期时间数据都在一个维度表中。（即日期键、GMT 日期、GMT 时间、IST 日期、IST 时间等...）
Kimball 建议从一天的时间维度中设置一个单独的日期维度，以防止表变得过大（数据仓库工具包第 240 页），这听起来不错，但这意味着我们在每个时区的事实表中有两个键我们需要支持（一个用于日期，一个用于一天中的时间）。
由于我在这方面非常缺乏经验，我希望有人知道这两种方法之间的权衡，即性能与所有不同时区键的管理。也许还有其他方法，我看到有些人谈论在每个时区的事实表中有一个单独的行，但这似乎是一个问题，如果你的事实表有数百万行，那么你需要将它翻两番来添加时区.
如果我们使用 15 分钟的粒度，我们的日期时间维度表中每年将有 131,400 (24 * 15 * 365) 行，这对性能来说听起来并不太可怕，但在我们测试之前我们不会确定原型查询。在事实表中使用单独的时区键的另一个问题是查询必须根据所需的时区将维度表连接到不同的列，也许这是 SSAS 为您处理的事情，我不确定.
感谢您的任何想法，-马特
我们使用 SQL Server 2008 R2 标准版（我们负担不起所有生产数据库服务器上的企业版），并且必须定期维护生产服务器中的关键索引（重建/重组）。问题是，由于我们使用的是标准版，因此我们无法访问重建索引在线选项。如果我们在重建这些关键索引时不限制对数据库的访问，我们会收到许多超时错误，因为在重建期间索引基本上是禁用的。我使用过诸如Ola Hallengren 的 Index Optimize script 之类的脚本，但这似乎并不能解决我的问题。
我想解决这个问题的方法是，当索引碎片化时，不要重建索引，而是创建一个单独的索引副本（即 IX_some_name_temp），一旦完成，删除原始的碎片索引，最后重命名副本索引回到原来的名字。我希望的是，在构建新索引时，Sql Server 可以使用原始索引（有点碎片化的索引），然后在构建新的临时索引后它可以开始使用那个索引，然后我们删除碎片索引并重命名和下次我们必须运行预定的作业时，我们将回到原始状态。
我的问题是，这种方法有意义吗？当我删除原始的碎片索引时，sql server 是否能够利用我的新临时索引副本？任何提示或可能的其他策略表示赞赏。