外键为啥必须是唯一键?为啥至少唯一键才能作为其他表的外键？不唯一为啥不可以？

Posted 2023-04-08

参考技术A 外键跟唯一键是2个概念，本质上都是约束，外键是关系中指定属性的值必须来源于另一个表的主键，或者null，而唯一键是关系中指定属性的所有可能值都必须不同或者null。
通俗地说，就是在一个或一组字段上既可以同时定义外键与唯一键，也可以单独定义外键或只五键，这2者没关系，只是对这一个或一组字段定义一个约束而已本回答被提问者和网友采纳

为啥新的 ASP.NET 标识表停止使用 Guid（唯一标识符类型）作为键？

【中文标题】为啥新的 ASP.NET 标识表停止使用 Guid（唯一标识符类型）作为键？

【英文标题】：Why did the new ASP.NET Identity tables stop using Guid (uniqueidentifier type) as keys?为什么新的 ASP.NET 标识表停止使用 Guid（唯一标识符类型）作为键？

【发布时间】：2015-08-21 07:23:21

【问题描述】：

我试图了解为什么新的 ASP.NET 标识表停止使用 Guid（唯一标识符类型）作为键 - 而是现在使用 nvarchar(128)，但仍保留 Guid 作为 string。 ..

这不是很大的浪费吗？ （uniqueidentifier 只是 2 个 integers 与整个 Guid 作为 36 个字符 string）

我怀疑实体框架可能对此负责......

改回唯一标识符键是否安全？

谁能告诉我使用 36 个字符串有什么好处？

【问题讨论】：

uniqueidentifier 是 16 个字节，而不是 8 个。字符串的大小不取决于它的长度，所以它实际上总是整个 256 个字节（nvarchar 每个“字符”有两个字节） ，对于任何索引和关联都是一样的。我想目标是灵活性，但这对我来说似乎是一个糟糕的权衡......

谢谢，由于某种原因，我有 Guid = 2 int 卡在我的脑海里......但我认为新的 SQL 服务器只分配正在使用的 nvarchar 字符数，而不是全部 128 如果只使用了 36 个 - 但仍然是一个很大的浪费......

我知道nvarchar(max) 可以做到这一点（即使这样也有一个最小长度 IIRC）和类似的，我还没有探索它是如何工作的。有可能他们解决了所有这些问题，但是我们不会简单地在任何地方使用nvarchar(max) 吗？ :D

我发现了另一个类似的讨论：***.com/q/23891446/809357 - 那里有一些很好的答案。

【参考方案1】：

Identity 可在多个存储平台上运行，并非每个存储平台都将 Guid 作为受支持的存储类型。

您可以将默认字符串 pkey 更改为 Guid，但这涉及到您的 C# 模型上的一些工作。或者您可以将 pkey 更改为 int - 无论您喜欢什么。请注意，有一个巨大的debate 关于which 是better。

【讨论】：

谢谢。我想知道除了支持其他 SQL 平台之外，是否有更正当的理由使用 128 nvarchar...那种性能损失是不可接受的......

嗯，EF 可以在这些平台上模拟 GUID，但为什么到处都这样呢？这听起来像是 EF 提供的抽象应该处理的事情之一。

@Luaan “到处都这样”是什么意思？如果您在存储类中创建Guid 属性并告诉EF 使用它，它将在SQL Server 中创建UNIQUEIDENTIFIER 字段。将 Guid 存储为字符串是身份框架的一种选择。

@trailmax 哦，这是对 Yovav 评论的回应。例如。如果要支持不支持 guid 的数据库引擎，那应该是 EF 的工作，而不是 Identity 的工作。

EF 提供的不成熟...尝试存储一个应该转换为 tinyint 但 EF 将其转换为 int 的字节字段