问题标签 [surrogate-key]

我们的 OLTP 系统使用多个代理键。现在我们要为我们的系统创建一个维度模型以进行分析。我们是否应该保留 OLTP 系统代理键和自然键，并且还要再创建一个数据集市代理键？还是我们应该忽略 OLTP 系统代理键，只保留 OLTP 和数据集市代理键的自然键？

我有一个员工维度，我使用 SCD 和代理键来跟踪随时间的变化。

员工业务系统密钥：EmployeeID

员工代理键：EmployeeSCDKey

我也希望随着时间的推移跟踪经理信息。经理和其他人一样是员工，因此，我正在考虑在我的 Employee 维度中有一个 ManagerSCDKey 列，如下所示：

例子：

这是我面临的问题。箭头显示了从一个变换到下一个变换的边界。如果经理更改了工作（或某些其他类型 2 SCD 字段）并为他们创建了新的代理键，则直到下次转换维度时才能识别该更改。

我的意思是红色的行直到第二次转换才会出现，因此这次与 Joe 关联的任何事实行都将包含过时的经理信息。

我想归结为：

有没有办法使这种模式起作用？（带有钥匙的维度？）

还是有更好的实践方法来完成相同的任务？我宁愿不维护与员工维度极其相似的经理维度，但如果这是最佳实践，那就这样吧。

我有几个系统，我需要将这些系统中的数据导入到一个公用表中。但 ID 仅在源系统内是唯一的。所以我需要创建自己的主键来唯一标识目标表中的这些数据。

解决问题的最佳做法是什么？我不想将主键创建为字符，也不想通过添加 1000000000 来生成 ID。与系统名称连接将构建字符数据类型。你有什么想法或解决方案吗？

感谢帮助。

我正在创建一个数据库来存储从多个来源恢复的移动应用程序的事件。问题是事件表中的行对用户没有多大意义，因为它主要是一连串整数。强制他们进行多次连接或多次查询。

我想直接使用“辅助”表的值作为我将在事件表中引用的主键（因为它是唯一的而不是空的）。它看起来像这样：

我认为这种方式也可能很好，因为在这种情况下我并没有真正看到使用代理键的附加值。还阻止我使用性能可能较慢的视图，因为每次我在查询中使用视图时它都会执行查询。

你觉得这个选项怎么样？

什么是 DW 中的集群代理键，它的用途是什么？

我要编写什么 T-SQL 代码来使 dimtable 中的列成为聚集代理键？

我看到了这条评论：

[应用程序] 与数据相关的问题最多的是使用自然键的应用程序。

资料来源：代理与自然/业务键

我想要更多的支持证据，因为评论留下了很多想象。

它表明使用自然键的做法会产生与数据相关的问题，但没有具体说明哪里出了问题……数据会损坏吗？不同步？变得错误、丢失、损坏？难查询？

当数据库设计为使用自然键而不是使用代理键时会发生什么数据问题？使用代理键时如何防止这些类型的问题？

我想了解在实时 DWH 环境中如何利用代理键。我知道他们增加了不依赖源生成的数据来存储每个维度键的好处，并且实际上还避免了由维度中的自然键构建的复合键，例如，（prod id + cust id+ time id）

但是，当我们将数据加载到事实中时，它是否不会增加必须维护（自然键、代理键）查找的复杂性。过去 3 年我一直在 BI/DW 团队工作，我们的系统中没有任何代理键。我们利用自然键来构建我们的数据集市。一个示例用例是存储在交易系统中的收入数据，该数据使用来自源的相同自然键以客户、产品、时间段粒度加载到仓库中。我们使用相同的方法加入相应的维度来构建 STAR 模式。

我认为在我们的案例中有意义的主要原因是企业使用 EDW 数据在帐户级别对数据进行微观分析，而不仅仅是趋势分析。在这种情况下，我们需要使用自然键来维护数据完整性。我想了解其他 DW 环境是如何工作的。您如何在系统中利用代理键或自然键。

谢谢！

是否有最佳实践如何防止在 ViewModel 中显示来自数据库的自动增量主键（ID），以使它们对最终用户不可见？

我知道表格上可能还有其他可以使用的唯一字段。但是，如果不确定是否存在（或将保留）一个独特的怎么办？

我正在考虑创建一个哈希并将其保存在数据库中名为 ViewKey 的列中。例如在表地址中。

目前我有几个pivot具有这种结构的表mysql：

用户 ID | 组织ID | 类型

如您所见，在我的type专栏中，我只使用externaland internal。当前，该type列是 aenum并已编入索引。

这是一个好的数据库结构还是我应该为该列创建一个单独的表type？

我在几张桌子上遇到了这个“问题”，所以这是一个重要的决定。桌子可能会变得很大。

在这个情况下，你会怎么做？

我正在做一个项目，我需要插入各种“产品”，但取决于类型（固定数量为 3，不会改变客户所说），“ID”应该以某个数字开头（2,3,4 )

虽然我的第一个想法是简单地使用（在删除的代码中）前缀，然后用“0”填充 id - 这不起作用，因为应该执行从“旧”系统的导入，其中 3 个表（而不是一个）已被使用。

因此，旧系统将提供（来自 3 个表）的 ID，例如

等等。（这是一个“懒惰”的设计，存储产品的表格区分了产品可能具有的 3 种状态之一 - 现在已简化为单个列 - 所有其他列都是相等的（基本属性），另外属性是EAV）

因此，应将 3 个表的混合数据集插入到单个表中，同时保留第一个“数字”（2,3,4）以供将来插入。

所以，我需要某种“插入”（根据自动增量产生代理 ID），但还需要基于“状态”创建人工 ID。

这种情况有哪些可用的选项？最好是“更少的代码”和“更多的查询”（如果可能的话，没有代码）