Sql server 将具有代理项的数据库拆分为物理层和逻辑层

我正在重建一个大仓库数据库，它最初使用自然密钥，现在我想切换到代理密钥

因此，我正在考虑将数据库分为物理层和逻辑层

在物理层中，每个表基本上有两个字段，如下所示：（简化案例）

TBL产品：

ProductKey bigint identity (1,1) not null primary key,
ProductID nvarchar(100) not null unique

TBL销售：

RowKey bigint identity (1,1) not null primary key,
ProductKey bigint not null references tblProducts(ProductKey),
DateSold date,
UnitsSold decimal,
UNIQUE (ProductKey, DateSold)

• “Key”字段始终是主键，也用于所有外键关系
• “ID”字段是唯一的nvarchar。用户将始终使用“ID”，而不会看到“密钥”

在逻辑层中，想法是为每个表创建视图，这将“隐藏”代理键，并允许我使用ID。甚至数据库管理员最终也应该只处理视图！例如：

查看销售情况：

select 
    prd.ProductID,
    sls.DateSold,
    sls.UnitsSold
from tblSales sls inner join tblProducts prd on sls.ProductKey = prd.ProductKey

现在，如果我想使用这个视图工作，我需要创建触发器来处理所有更新/删除/插入，并将其“转换”到物理层。创建所有这些视图需要大量的工作。因此：

• 有没有办法“自动”创建这样的视图
• 将数据库拆分为物理层和逻辑层是一种很好的方法吗

  ---

虽然有一种方法可以自动创建DDL，但我可以根据经验告诉您，这不是您想要的方法

是的，创建代理密钥是数据仓库中的最佳实践（我们就是这样做的）。是的，您可以在视图或维度层中隐藏代理键（我们也会这样做），自动创建与基础数据基本相同的视图（代理键除外）会给您带来不必要的复杂负担，我相信您最终会后悔的

爱因斯坦有句名言：“一切都应该尽可能简单，但不能简单。”

最初构建数据仓库的供应商加入了一个创建DDL的过程，该DDL为每个物理表创建一个视图。出于好意，这些视图提供的价值很小，成为维护问题，不必要地使组织良好的DW变得混乱。我们最终删除了所有这些观点

您仍然可以获得拥有不同逻辑层的好处。我建议使用视图来构建维度层。我们只向希望使用DW数据的业务用户公开“逻辑”维度层视图

---

我强烈建议您研究ELT相对于传统ETL流程的好处。它彻底改变了我们的DW方法，并实现了您可能在逻辑层寻求的好处

这听起来像是一个寻找问题的复杂解决方案。具有星型模式的数据仓库应该足够简单，提取ID只使用简单的明显连接。@Nick.McDermaid您的意思是我们应该使用自然键？抱歉，我指的是逻辑视图部分很复杂。使用代理键而不是（或以及）自然键是一个合理的设计决策。非常感谢，这是一个非常有建设性的答案！与此同时，我也放弃了为所有内容创建完整的“逻辑层”的想法。我们保留代理密钥并将其隐藏起来，但将通过过程处理所有事情。我将研究ELT与ETL.PS：在我25年的仓库经验中，我创建了带有或不带代理密钥的数据库。两者各有利弊。最大的“缺点”是您无法“人工”读取任何数据，并且对于每个操作，您都需要构造复杂的查询。最大的“优点”是完全灵活的重命名，您可以创建一个直接的逻辑层，它依赖于每个表中存在一个键。@这是一个很好的答案。关于你对ELT和ETL的最新评论，你有/推荐任何好的资源吗？我目前正努力在整个ETL实践中找到一种“现代”方法。