aan*_*dis 11 postgresql primary-key unique-constraint
我是数据库的新手。我四处阅读并发现使用电子邮件地址作为主键可能不是一个好主意,因为字符串比较速度较慢,这会影响复杂连接中的性能,如果电子邮件发生变化,我必须更改所有需要很多的外键的努力。
但是如果我的用户表要求每个用户都有一个电子邮件地址并且每个电子邮件地址都应该是唯一的,那么在电子邮件列上添加一个唯一索引就足够了吗?因为 afaik 唯一字段允许空值,而我要求每个用户都有一个电子邮件地址,不允许空值。有什么我在这里想念的吗?或者我想使电子邮件列唯一并确保在服务器上的数据验证期间用户确实输入了一个电子邮件地址,以便每个用户都有一个?
我们先来区分键和索引,键是逻辑模型的一部分,通常用唯一索引来实现。但是,您可以在不创建键的情况下创建唯一索引,但不能被外键引用。
候选键是唯一标识表中一行的东西,在 SQL 中,其中一个候选键通常用作主键(我从来没有真正理解为什么其中一个 ck 被认为比其他的“更好”,但这是另一个故事),剩下的 ck 成为唯一约束。
可以像使用主键一样使用唯一约束。考虑:
create table A ( x ... not null
, y ... not null
, z ... not null
, unique (x)
, primary key (y,z) );
create table B ( x ...
, ...
, foreign key (x) references A (x) );
create table C ( y ...
, z ...
, ...
, foreign key (y, z) references A (y, z) );
Run Code Online (Sandbox Code Playgroud)
B 引用唯一约束,C 引用主键约束。
NOT NULL 是另一种约束。在您的情况下,您可以在不声明其唯一性的情况下对电子邮件强制执行此操作。
您帖子的下一个方面涉及密钥的稳定性,密钥应该是稳定的(但这并不意味着它永远不会改变,它不必是一成不变的)。一些 DBMS 实现了 ON UPDATE CASCADE 可以为此类操作提供帮助,但如果密钥分布在您的模型周围,则更新它会很痛苦。
在您的情况下,我可能会选择另一个候选键作为主键,并将电子邮件声明为 NOT NULL 和 UNIQUE。
是的,在 EmailAddress 列上有一个唯一索引应该没问题。唯一的问题是,如果有人在注册您的服务后放弃了电子邮件地址但没有告诉您,那么该电子邮件地址的所有者会尝试注册。但这是一个非常罕见的边缘情况。
至于唯一索引是否允许空值,这取决于您的数据库平台。Oracle 确实如此,SQL Server 允许单个 NULL 值。您可以通过使列不允许 NULL 值来解决此问题,然后在其上构建唯一索引。
| 归档时间: |
|
| 查看次数: |
8092 次 |
| 最近记录: |