【问题标题】:Unique Key Constraint Issue - MySQL, SQL Server, Oracle, Postgres唯一键约束问题 - MySQL、SQL Server、Oracle、Postgres
【发布时间】:2019-05-13 16:57:37
【问题描述】:

我有一个包含 10 列的员工表,并且必须为 id、姓名、地址、移动设备创建唯一键约束

在上述情况下,地址可能会为空,而手机也可能为空。但是,当它们出现时,应该保持唯一性。

首先,我通过组合上述所有键创建了一个唯一约束并观察到以下情况。

MySQL 中的实际行为。

   001-Thiagu-NULL-900000 - Accepted
   001-Thiagu-NULL-900000 - Accepted
   001-Thiagu-0001-900000 - Accepted
   001-Thiagu-0001-900000 - Rejected - Duplicate Record

所有数据库中的预期行为

   001-Thiagu-NULL-900000 - Accepted
   001-Thiagu-NULL-900000 - Rejected - Duplicate Record
   001-Thiagu-0001-900000 - Accepted
   001-Thiagu-0001-900000 - Rejected - Duplicate Record

无论值是否以NULL或Not存在,基本上都应考虑重复。

为了克服这个问题,我放弃了通过将列添加到唯一约束来组合和创建唯一的想法,并提出了一个具有唯一约束的字符串类型的新列。

我手动构造记录的每个插入并在任何插入上给出值,以便保持唯一性。

这是我不确定的上述第一种方法的正确方法还是任何其他方法。

创建的约束应该适用于 MySQL、SQL Server、Oracle 和 Postgres。

【问题讨论】:

标签: database


【解决方案1】:

在 SQL 中,null 永远不会等于 null。这不是一个错误,这是一个功能。 NULL IS NOT DISTINCT FROM NULL 是真的,但是键声明使用 '=' [在等效的长记中],而不是 IS NOT DISTINCT FROM。您想要的“键”约束应该使用 IS NOT DISTINCT FROM,因此您无法通过声明键来实现。

下一个选项是 CHECK 约束,但产品不太可能支持 CHECK 约束访问除插入行之外的其他行。

下一个选项是创建一个 ASSERTION,但没有产品[可靠地]支持它,本质上与它们不支持跨行 CHECK 约束的原因相同。

下一个选项是在存储过程中强制执行此操作,但您可能会遇到 [一些] 产品只使用其专有的 SQL/PSM 语言方言。

下一个选项是应用程序代码。

【讨论】:

    猜你喜欢
    • 2011-02-17
    • 2013-01-01
    • 2013-10-18
    • 1970-01-01
    • 2014-11-28
    • 2020-05-03
    • 2015-03-06
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多