如何在关系数据库设计中处理 null 列

Question

虽然主要使用非关系数据库，但我需要切换齿轮并使用关系数据库，因为我需要构建的应用程序将运行复杂的查询，并且需要表之间的连接操作。

在开始创建数据库本身之前，我必须考虑架构，并且我已经为数据库设计设置了一个 UML：

这就是TransactionDEpositBreakdown表的外观：

id  amount  date        reference_number  batch_id   payment_processor_id  mid_id  main_dep_id
1   100     2020-10-11  900               null       1                     100     2
2   101     2020-10-11  900               null       1                     100     2
3   102     2020-10-11  900               null       1                     100     1
4   103     2020-10-11  350               null       1                     100     1
5   104     2020-10-11  350               null       1                     100     3
6   105     2020-10-11  600               null       1                     100     4
7   106     2020-10-11  null              1000       2                     201     null
8   107     2020-10-11  null              1001       2                     201     null
9   108     2020-10-11  null              1002       2                     201     null
10  109     2020-10-11  null              1003       2                     201     null

• 一个reference_number可以分配给多个交易存款明细
• 一个batch_id只分配给一个交易存款明细

有一个用例，其中TransactionDepositBreakdown可能具有reference number或batch id ，具体取决于支付处理器类型（类型 1 - 参考号，类型 2 - 批次 id）。 我不确定如何处理这种情况，但我正在考虑以下选项：

1. 添加两个表TransactionDepositBatch和TransactionDepositReference ，它们将transaction_deposit_id作为外键，第一个表上的batch_id和后一个表上的reference_number ：

2. 保留TransactionDepositBreakdown表中的reference_number和batch_id列，并根据支付处理器类型始终拥有其中一个null 。

注意：可能需要在TransactionDepositBreakdown表中添加另一列，例如card_type ，仅当支付处理器类型为 1 时才会分配一个值。

考虑到上述说明，第一个选项是处理此问题的正确方法吗？

此外，任何关于我构建的 UML 的建议都会非常有用。

Answer 1

这些关系之一很难在关系数据库中使用 model。 不同的数据库有不同的能力，所以有些可能有可以应用到这个问题的扩展（比如 Postgres 对表继承的支持）。

你的情况很简单，只有两种选择。 在这种情况下，我将 go 作为第一个选项，原因很简单：它很容易让您设计具有声明外键关系的数据 model。 缺点是两个外键都需要空间，即使其中一个是NULL 。

您还可以强制设置一个或另一个，但不能同时使用检查约束：

constraint chk_TransactionDepositBreakdown_reference_or_batch 
    check (reference_number is null or batch_id is null);