问题标签 [surrogate-key]

我正在用 Rails 编写一个新应用程序，所以我在每个表上都有一个 id 列。使用外键强制域约束的最佳实践是什么？我将概述我的想法和挫败感。

这就是我想象的“Rails Way”。这是我开始的。

这样做的问题是，来自一家公司的产品可能出现在另一家公司的发票上。我向 LineItems 添加了一个 (company_id: integer, not null)，有点像我只使用自然键和序列号时所做的，然后添加了一个复合外键。

这将 LineItems 适当地限制为一家公司，但它似乎过度设计和错误。LineItems 中的 company_id 是无关的，因为代理外键在外表中已经是唯一的。Postgres 要求我为引用的属性添加一个唯一索引，因此我在产品和发票中的 (id, company_id) 上创建一个唯一索引，即使 id 只是唯一的。

下表包含自然键和序列发票编号不会增加这种复杂性，因为引用的列已经是自然键，因此它们已经具有唯一索引。

我可以忽略 LineItems 表中的代理键，但这似乎也是错误的。当数据库已经有一个整数可供使用时，为什么要在 char 上加入数据库？此外，完全按照上述方式进行操作将需要我将 company_code（自然外键）添加到 Products 和 Invoices。

妥协...

不需要其他表中的自然外键，但当有可用整数时，它仍然在 char 上加入。

有没有一种干净的方法可以像上帝预期的那样使用外键强制域约束，但是在代理存在的情况下，而不会将模式和索引变成复杂的混乱？

我必须用 12 次查找维度表来填充 FactTable 以获得 SK，其中 6 次查找不同的 Dim 表，其余 6 次查找相同的 DimTable（类型 II），查找相同的自然键。

前任：

PrimeObjectID => 查找 DimObject.ObjectID => 获取 ObjectSK

并得到了其他相同的列

OtherObjectID1 => 查找 DimObject.ObjectID => 获取 ObjectSK

OtherObjectID2 => 查找 DimObject.ObjectID => 获取 ObjectSK

OtherObjectID3 => 查找 DimObject.ObjectID => 获取 ObjectSK

OtherObjectID4 => 查找 DimObject.ObjectID => 获取 ObjectSK

OtherObjectID5 => 查找 DimObject.ObjectID => 获取 ObjectSK

对于这样的多重查找，我的 SSIS 包中应该如何进行。

现在我正在使用查找 / unionall foreach 查找。有没有更好的方法。

首先，我们使用 JPA 2.0 和 Hibernate 3.5 作为 PostgreSQL 数据库上的持久性提供程序。

我们通过 JPA 2.0 注释成功地将数据库序列用作单字段代理键的自动生成值，并且一切正常。

现在我们正在实现一个双时态数据库方案，该方案需要以下方式的混合键：

现在我们有一个问题。你看，如果我们INSERT是一个新元素，该字段id是自动生成的，这很好。只有，如果我们想要UPDATE在这个方案中的字段，那么我们必须更改validTimeBegin列而不更改id-field 并将其作为新行插入，如下所示：

在更新行之前：

在恰好 2010-05-01-10:35:01.788 服务器时间发生的行更新之后：

所以我们的问题是，使用自动生成的字段序列这根本不起作用，id因为当插入新行时，id 总是自动生成的，尽管它确实是复合键的一部分，有时应该表现不同。

所以我的问题是：有没有办法通过 JPA 告诉休眠停止自动生成id-field，以防我想生成同一个人的新变种，并在其他情况下照常继续，或者我必须用自定义代码接管整个 id 生成？

在此先感谢，杰拉德

对象A具有一对多关联：许多对象B。

当我查看数据库时TableB——我希望看到唯一的、可读的字符串，A.Name而不是总是在代理整数标识符上加入或子选择来查看名称。

我可以映射Name为 的标识符A，但这会导致大量额外的SELECT查询，因为 NHibernate 无法识别 的实例A是瞬态的还是持久的。

我想我可以使用复合键，将本地分配的代理键与自然键结合起来。这似乎不是最理想的，但我很想听听一些意见。

我真正想要的是一种使用单列自然键同时允许 NHibernate 识别瞬态实例的策略。

• 可能吗？
• 什么是映射——fluent 还是 hbm？

另一方面，如果这一切都是一个糟糕的想法，我应该只依靠带有子选择的数据库视图，请解释一下。

谢谢。

哪一个是最佳实践，为什么？

a) 类型表，代理/人工键

外键是从user.type到type.id：

b) 类型表，自然键

外键是从user.type到type.typeName：

我的表架构是这样的

1.主表：子句

列

1. ClauseID = 代理 pk（身份）
2. ClauseCode = nvarchar 用户指定值
3. Class = nvarchar FK 到主类表
4. ETC...

ClauseCode + Class = 此表的候选键

2.主表：GroupClause

列

1. GroupClauseID = 代理 pk（身份）
2. GroupClauseCode = nvarchar 用户指定值
3. Class = nvarchar FK 到主类表等...

GroupClauseCode + Class = 此表的候选键

3. Transaction / Mapping table :: GroupClause_Clause_Mapping：该表将每个组子句映射到多个单独的子句

列

1. GroupClauseID = FK 到 GroupClause PK
2. ClauseID = FK 到条款 PK
3. ETC...

要求：每个组子句只能映射到与自己属于同一类的子句

问题：上表设计并未在数据库级别强制执行该要求。

一种可能的解决方案：表 *GroupClause_Clause_Mapping* 有列

1. 条款代码
2. 组条款代码
3. 班级

其中我可以创建 ClauseCode + Class 作为 FK 到子句表以及 GroupClauseCode + Class 作为 FK 到 GroupClause 表。

但是，如果我这样做，那么代理身份密钥就没用了，我不妨摆脱它们。

使用代理键的设计是否存在问题？

关于如何使用代理键并仍然在数据库级别强制执行我的约束的任何建议？

我看到很多应用程序使用哈希作为代理键而不是普通整数。我看不出这种设计有什么好的理由。

鉴于大多数 UUID 实现只是散列时间戳，为什么这么多数据库设计人员选择它们作为应用程序范围的代理键？

I've got two tables:

Entries in the database might look like this:

Document:

Section:

Document has a generated Id on DOC_ID, while Section has a composite primary key over DOC_ID and SECTION_NUM.

SECTION_NUM is a locally(application) generated sequence number starting fresh for every document.

My entity classes look as follows:

When inserting a new Document and related Section, I do the following:

When persisting I get an exception stating that NULL is not allowed for column SECTION_NUM. I'm using OpenEJB (which relies on OpenJPA behind the scenes for unit testing), and found when stepping through OpenJPA code that it successfully persists the Document object, but when it comes to the Section object it creates a new instance reflectively and sets all fields to null, so losing the sectionNum value, before linking it to the Document object persisted earlier.

Unfortunately I can't change the DB schema, as it's a legacy system. Has anybody done something similar and got it working?

我想知道构建和存储 ID 的最佳实践是什么。几年前，一位教授以社会安全号码为例，向我讲述了构建不良的 ID 系统的危险。特别是，因为 SSN 没有任何错误检测功能……无法区分 9 位字符串和有效 SSN。现在政府机构需要诸如姓氏 + SSN 或生日 + SSN 之类的东西来跟踪您的数据并确保其验证。另外，根据您的出生地，您的社会安全号码在某种程度上是可以预测的。

现在我正在构建一个用户数据库......根据这个建议，“userid mediumint auto_increment”是不可接受的。特别是如果我打算将此 ID 用作用户的主要标识。（例如，如果我允许用​​户更改他们的用户名，那么用户名将比数字用户 ID 更难跟踪......需要级联外键等等。）电子邮件更改，用户名可以更改，密码更改.. . 但是用户标识应该永远保持不变。

显然，auto_increment 只为 surrogate_keys 设计。也就是说，仅当您已经拥有主要标识机制时，它才是有用的快捷方式，但不应将其用作数据的“固有标识符”。创建随机 UUID 看起来很有趣，但随机性让我很反感。

所以我问：创建“主键”标识号的最佳实践是什么？

我必须为 C#/.NET WinForms/Desktop 应用程序添加一些安全性。我正在使用 Oracle DB 后端。

这些表很简单：用户（ID，名称），角色（ID，角色），用户角色（用户ID，角色ID）。

我正在使用 Windows 帐户名称来填充用户表。角色表现在只是'Admin'，'SuperUser'，'BasicUser'......

因为不可能有两个人拥有相同的 Windows 帐户名......即使我不控制这些名称管理（netops 可以，因此我想使用 Windows 帐户所以我不必管理它;)）。对于角色表，我不应该再有欺骗值 - 我控制输入，只有 3 个（战术应用程序在一年内消失）。UserRole 是一个连接表，表示用户和角色的多对多关系，因此没有代理键是合理的。

简单的问题 - 为什么要在用户和角色表中使用“ID”（int）？这里有什么要点或优势吗？这是那些“我一直都是这样做的”类型的事情之一吗？还是我只是有一段时间没有这样做而忘记了原因？