我正在考虑将用于更新这些表的登台表和存储过程放入自己的架构中。这样当从SomeTable导入数据到数据仓库时,我会运行一个Initial.StageSomeTable过程,该过程会将数据插入到Initial.SomeTable表中。这样,处理Initial staging的所有proc和表都被组合在一起。然后,我将为ETL的那个阶段提供验证模式等。
这似乎比尝试唯一地命名所有这些非常相似的表更简洁,因为每个表在整个分段过程中都有多个自身实例。
问题:是否正在使用用户架构将表/ procs / views组合在一起,以便在MS SQL Server中正确使用用户架构?或者是用户模式应该用于安全性,例如将权限分组为对象吗?
答案 0 :(得分:1)
我认为这是合适的,它并不重要,你可以使用另一个数据库,如果你喜欢它实际上是我们做的。
我不确定为什么你会想要验证架构,你打算在那里做什么?
答案 1 :(得分:1)
您列出的原因(目的/意图,安全性)都是使用模式的正当理由。一旦开始使用它们,就应该在引用对象时指定模式(虽然我很懒,但从不指定dbo)。
我们使用的一个技巧是在几个模式中的每个模式中使用相同名称的表,并结合表分区(在SQL 2005及更高版本中可用)。在第一个模式中加载数据,然后在验证时将分区“交换”为dbo - 将dbo分区交换为表的“dumpster”模式副本。净生产停机时间以秒为单位进行测量,并且所有停机时间均小心地包含在已声明的交易中。
答案 2 :(得分:1)
这实际上是推荐的做法。从 Business Intelligence ETL Design Practices 查看Microsoft Project Real 。您会发现(从第一个链接下载文档)他们使用了相当多的模式来分组和识别仓库中的对象。
除了dbo和etl之外,他们还使用admin,audit,part,olap等等。