问题标签 [surrogate-key]

我目前正在决定是管理我自己的 Varnish 服务器还是使用像 Fastly 这样的托管服务。这里最重要的决策因素之一是有效的基于标签的缓存失效，因为我计划将 Varnish 放在我们的 API 前面，并且我们需要经常发出使许多相关页面失效的清除请求。

Fastly 提供了代理键，而 Varnish 似乎提供了一个单独的模块，该模块有多个名称，包括 Hashtwo、Hashninja 和 XKey。这些功能似乎是相同的。它们实际上是否相同，或者这两个功能之间是否存在一些关键的技术或效率差异，这在有关它们的博客文章中并不清楚？

我了解在数据仓库维度中使用代理键有充分的理由。不过，我不明白如何将它们链接到我的事实表的外键。在事实表中，我只有自然键，在 ETL 期间提取。原始数据库表中不存在代理键。对此有什么建议吗？谢谢

我有一张记录许可证使用情况的表格。每个许可证使用都需要与用户和主机相关联。表定义如下所示。

我想规范化这个表，以便将重复的用户/主机值移动到这样的新表中。

对于user_host表，我应该选择什么样的主键 - 自然或代理？我可以想到以下控制因素。

1. 如果主键是自然的，即用户名和主机名的组合，则父表per_user_fact不需要额外的连接来查找用户名和主机名。
2. 如果主键是自然的，则会浪费存储，因为用户名和主机名值将在两个表中重复。
3. 如果主键是代理项，则父表将需要额外的连接来获取用户名和主机名的值。
4. 如果主键是代理，对 user_host 表的索引会更快。

请指教。

考虑数据库规范化规则时首选哪种表设计：

考虑描述有序树的节点表的以下设计。密钥是复合密钥。

• ck：复合键
• parent：父节点
• next：下一个节点，其中next.parent = parent.
  （这定义了一个前向链表）
• sk：代理键

设计一：

设计二：

设计3：

第一个设计有 6 列。第二种设计增加了一个替代键，有 7 个列。第三种设计有 5 个列，它使用代理项来保存一列。

是否有任何规范化规则（或其他数据库设计规则）更喜欢一种设计而不是其他设计？

更新

替代设计：子类型节点表、isParent 标志、嵌套集。这些设计具有更大的读/写复杂性。

设计4：

• 此设计将表拆分为 3 个表。父表和下一个表包含来自节点表的键的互斥子集。它2+4=6为每个节点使用列。

  node(ck_x, ck_y)

  parent(ck_x, ck_y, parent_ck_x, parent_ck_y)

  next(ck_x, ck_y, next_ck_x, next_ck_y)

设计5：

• 此设计使用 isParent 标志来指示下一项是父项。它使用4+1=5列，1 列只是一点点。这比设计 3 中使用的 5 列空间小）

  node(ck_x, ck_y, next_ck_x, next_ck_y, isParent)

设计6：

• 此设计使用嵌套集来创建有序树。复合键不再用于定义父级或子级的顺序。它使用2+2=4列。但是下限列和上限列都应该使用sizeof(ck_x)+sizeof(ck_y)等于设计 1 中使用的 6 列的空间。

  node(ck_x, ck_y, lowerBound, upperBound)

更新

设计7：

• 这使用了节点位置的索引。

  node(ck_x, ck_y, parent_ck_x, parent_ck_y, index)

笔记

• 与插入和更新相比，使用前一个节点 iso 下一个节点减少了对单个插入的创建和添加。

• 规范化与列或表的数量无关。

我搜索了以下问题的答案，但得到的答案主要与是否使用代理项有关，而不是关于是否在连接表的子项上使用复合键。

我有一张桌子attendees和一张桌子events。

连接表是event_attendees，包含两个外键attendee_id和event_id，还有一个代理主键id

现在假设参加活动的参与者可以拥有schedule_items.

我通常会简单地使用表event_attendee_id中schedule_item_id的列event_attendee_schedule_items。

使用以下复合外键设置有哪些缺点（如果有的话）？

attendee_id, event_id, schedule_item_id（复合键而不是event_attendees表的直接链接）？

有没有办法在 Pig 中创建自定义代理键？

例如：我们有如下数据

对于这些数据，我们需要创建如下代理键，结果应如下所示。

而不是创建随机唯一键？

提前致谢！！。

我们即将为我们的站点设置缓存和反向代理，我们正在决定是使用 Varnish 还是 Nginx。我们有复杂的缓存清除要求，我们实际上需要代理键（或基于标签的）缓存失效。

Varnish 为Hashtwo提供了这个功能。Nginx 是否以任何形式提供此功能？

我正在阅读有关 DW 建模的内容，并开始想知道为什么要使用代理键？

我知道有时业务键不是整数，这会使生活（以及连接和索引）变得更加困难。但是，我不明白为什么要通过添加额外的列来管理唯一标识符来解决 DW 或 RDBMS 的限制？

这种功能对 DW/RDBMS 用户是透明的，并且条目会自动从系统获取内部标识符，这不是更合适吗？例如，创建整行或其子集的 SHA-1 摘要（可以以某种文本格式表示的那些字段）。

我正在模拟一家航空公司。我有一张“乘客”表

如果我是正确的，我会说乘客确认号和航班号是代理键。我想知道的是，在这种情况下，诸如 seatNum 之类的属性也将是 asurrogate key或将被视为 a natural key。

假设我有一个地址表，其中包含制造公司不同设施的地址。外键让我知道地址属于哪个公司，但我需要一个代理 ID 来区分每个设施。此 id 应根据外键值自动递增。注意：我只需要简单的整数值作为键。

例如：

我的表有以下列，ORGANIZATION_ID 是外键。FACILITY_ID 是依赖于外键的第二个代理键。

我希望设施 ID 根据组织 ID 从 1 自动增加。IE

当我为新组织插入数据时，设施应从 1 开始

下次我为同一组织插入数据时，我的设施 ID 应相应增加 -

有什么方法可以在 DB2 中实现这一点？我目前使用的是 DB2 V 10.5.6