绕过 UNIQUE w NULL 约束的可接受的方法？

Question

我有一个表如下：

我想添加UNIQUE KEY一个(connection_id, parent_container_id, name). 然而，parent_container_id和connection_id是不相交联合——记录必须具有其中之一。因此，我想也许可以使用该值1作为“空”值（即使用自动递增 ID 时的第一个条目），并在表中container为记录创建一个 BASE 条目1。

我想要强制执行唯一性的示例数据：

• （connection_id = 1，parent_container = null，名称=“你好”）

• (connection_id=1, Parent_container=null, name="hello") # 应该失败

• （connection_id=null，parent_container=10，name=“再见”）

• (connection_id=null, Parent_container=10, name="goodbye") # 应该失败

这是一种糟糕的使用方法还是这似乎是强制执行唯一性约束的好方法？如果这不是一个好方法，那么什么是更好的方法呢？

---

更新：我当前的解决方案现在使用带有 md5 哈希值的生成（虚拟）列：

ALTER TABLE container ADD unique_hash2 CHAR(32) GENERATED ALWAYS AS 
(MD5(CONCAT(COALESCE(connection_id, '-1'), COALESCE(parent_container_id, '-1'), name))) VIRTUAL UNIQUE

Answer 1

关系解决方案

在这种情况下响应标签relational-database。SQL 是 Codd 在他的关系模型中定义的数据子语言，该模型于 1980 年代被确立为标准。因此 SQL 是关系型的；关系型就是SQL。

• 这个答案中的所有项目都是关系型的，可以在 SQL 中轻松实现，我们已经拥有它们几十年了。

这是一种糟糕的使用方法还是这似乎是强制执行唯一性约束的好方法？如果这不是一个好方法，那么什么是更好的方法呢？

是的，它很穷，有两个方面。首先，您试图在一个文件中执行太多操作。第二，它不是Relational的，并且有干净的；在关系范式中执行此操作的逻辑方法：因此您的预期添加是有问题的。

• 这不是数据库设计问题，而是严格回答错误，并给出解释。

1. 容器
   container_id; name并parent_container_id指示简单的单父层次结构。这是一个事实。

   • 由于您有多个数据树或层次结构，每个数据树或层次结构都有一个根，因此您需要一个值为container_id0 的锚行，根是其子级，并通知构造Path或PathName何时停止的递归函数。这是一个 Anchor 行，它意味着一些东西，它不是避免 Null 的小提琴。
   • 需要AK ( parent_container_id, name )防止parent_container_id. 这是一个谓词。不要加倍并尝试用它做更多事情，而是添加另一个谓词。

2. 连接
   connection_id是一个单独的离散事实。我认为它仅适用于根。所以这是一个从属事实，对于[1]来说是可选的。它的完整性由调用函数（与子类型文档中相同）的约束来维护，该函数检查父项是否为根。

   • Null 是一个红色标志，表示标准化不完整，如果对数据进行标准化，则不会存储 Null。（当然，结果集中允许有空值。）

   • 另外，通常，由于 Null 是未知数，因此UNIQUE未知的 Key ( ) 的概念是歇斯底里的。这就是标准禁止这样做的原因。

3. “联合类型”
   在关系范式中，“联合类型”的概念彻底破产了。这是不了解关系模型或 SQL 的学者所使用的方法，他们教授和推广 1960 年代的记录归档系统和数据库系统，但没有正确实现 SQL 标准。由于这些数据库系统不支持 SQL（调用函数的约束），因此该方法是一种可能的替代方法：在父级中添加一个附加索引，在子级中添加一个附加外键。每个级别都很可怕。不要将其用作通用方法。

   • 请注意，附加索引在索引意义上是反常的（container_id已经是唯一的；向唯一字段添加某些内容不会使其变得更唯一），其唯一目的是允许子级中存在外键，而外键又会检查某些条件（这里，父级是根）。

   • 显然，如果你的“SQL”不是 SQL，请使用假装“SQL”方法

4. 析取
   要实现“或”或“异或”门（形式析取），请使用适当的子类型簇（而不是重载已经很差的文件）。

数据模型

该模型提供了一个relational-database解决方案，它暗示了 SQL，因此也意味着可以调用函数的适当约束。

• 它受到损害，因为“主密钥”不是密钥，而是物理密钥RecordId，不具有逻辑密钥的属性。结果将在子表中注意到。

该模型提供了在 MySQL 中可行的解决方案。

• 典型的 1960 年代前关系型、前 DBMS 物理记录归档系统，被学术界称为“关系型”，

• 使用附加索引和 FK 来替代 SQL 约束，用于未正确实现 SQL 的数据库

符号

• 我所有的数据模型都是在IDEF1X中呈现的，IDEF1X 是 1980 年代初推出的，它是 1993 年唯一的关系数据建模标准。

• 对于刚接触 Codd关系模型或其建模方法的人来说， IDEF1X简介是必不可少的读物。请注意，IDEF1X 模型是完整的，它们具有丰富的细节和精度，显示了所有必需的细节，而本土模型由于不了解标准的要求，因此定义要少得多。这意味着，需要完全理解该符号。