SQL 设计问题。唯一索引/约束与代理键

Posted 2023-05-09

【中文标题】SQL 设计问题。唯一索引/约束与代理键

【英文标题】：SQl Design issue. Unique Index/Constraint vs Surrogate Keys

【发布时间】：2011-11-02 14:46:42

【问题描述】：

出于各种原因，我决定使用代理键（以种子身份的形式）。我的问题来自强制数据唯一性。例如，假设我正在创建一个数据库来存储图书馆中的所有书籍。

isbn 是分配给来自图书出版界某个神奇来源的所有图书的唯一标识符。如果这本书是印刷的，它有 1 个 isbn，如果它是电子的，它有另一个 ISBN。

如果不放置一个覆盖打印的ISBN 和ElectronicISBN 列的uniqueIndex，我们就无法强制ISBN 具有唯一性。我的具体问题是，我们有这种情况，我们需要强制数据的唯一性，但我们使用代理主键，我们必须强制数据唯一性的唯一方法是在我们想要的列上放置唯一索引喜欢强制执行。 这似乎违反直觉，因为如果我们在整个设计过程中都遵循代理键方法，那么每个表都会有一个代理主键和一个唯一索引？这似乎很糟糕，我觉得我的设计能力还不足以找到“正确的答案”。在这些类型的场景中，答案是什么？

BookID INT IDENTITY (1,1) not null,
Title varchar(25) not null,
Author varchar(25) not null,
PrintISBN char(13) not null,
ElectronicISBN char(13) not null

【问题讨论】：

一个可能的答案是您将 ISBN 详细信息规范化到另一个表、BookID、ISBN、ISBNType、OtherMeta 字段 - 然后在 ISBN 上放置唯一约束就很简单了。

有道理。让主键是 isbn 有一个列是 isbn 类型，然后有另一个具有 typeID、ISBN 类型的表。只要我将其与以下类型相关联，这将允许我将任何类型的 guid 放在那里，所以如果他们推出“isbnMark”版本，我可以轻松适应它。

【参考方案1】：

（转换形式的 cmets）

应该将 ISBN 规范化为单独的表格。对于给定的书籍，您可能会处理多个 ISBN，无论是实体媒体的精装本、软装本、盲文，还是有声读物和电子书电子版。我们甚至没有考虑这本书的翻译版本是否是一个单独的数字。

出版给定作者的书有多种方式，我认为您不应该将 ISBN 限制为 2 - 1 种印刷版、1 种电子版。

然后可以毫无问题地强制执行唯一性。

【讨论】：

伟大的评论和观点。我正在解决更通用的问题“您能否在具有代理键的表中的第二列上强制执行唯一性”并且您绝对可以（并且您应该识别并选择自然键）但是这个答案触及了特定的核心OP 的情况，并导致思考更好的数据库设计。

【参考方案2】：

如果书是印刷的，它有 1 个 isbn，如果是电子书，它有另一个 ISBN。

我怀疑这只是众多分类之一，例如精装本、平装本、有声读物、Kindle、CD、下载。还要考虑多个出版商、语言、地区等。使用 ISBN 的一大好处是您不必担心任何这些：您只需要知道项目的 ISBN 编号，然后将其与另一个项目的 ISBN 进行比较编号来确定它们是否被认为是相同的。

【参考方案3】：

在同一个表上拥有唯一索引和代理键是没有问题的。事实上，在使用代理键时仍然需要声明“自然键”索引并使其唯一（否则它只是一个人工键，即它不是任何东西的代理）。

我当然会在 ISBN 上创建唯一索引以强制它们的唯一性，同时让查询优化器知道列中的数据是唯一的。我们提供给查询优化器的信息越多，生成的计划的执行效果就越好。

【讨论】：

这种方法不会通过在列上添加额外的索引而借给大型数据库文件吗？

您会使用 ISBN 进行搜索吗？如果是这样，那并不是一个糟糕的索引。 13 字节 x 行数。

但是您的问题可能在于同时拥有两个 ISBN。如果一本书没有电子版怎么办？当它只有电子版时，你会怎么做？一种解决方案是创建一个允许空值的过滤唯一索引 - ***.com/questions/767657/…

拥有第二把钥匙肯定是代理人的先决条件吗？否则，它只是一个人工密钥，即它不是任何东西的替代品。

@onedaywhen- 代理键是否需要第二个键？我不知道。强制执行数据完整性对它来说是有意义的。当有更好的方法时，我只是不想设计一个使用一堆辅助键的东西。我决定用安德鲁斯的评论作为我的问题的解决方案。但是很高兴知道使用带有代理键的辅助键几乎是一种标准。谢谢

【参考方案4】：

是的，每个表都应该有一个自然键（也称为“业务键”），无论它是否还有代理项。使用唯一性约束来强制执行键。除了这些限制之外，indexes 的正确使用是一个不同且本质上不相关的问题。

如果不分析业务需求，我无法说 ISBN 是否是您的表的正确业务密钥。可以说应该有某种方法来识别您在业务领域中建模的实体。