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

在主要处理非关系数据库时，我需要切换设备并使用关系数据库，因为我需要构建的应用程序将运行复杂的查询，并且需要表之间的连接操作

在开始创建数据库之前，我必须考虑体系结构，并为数据库设计建立了一个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

• 可为多笔交易存款明细分配

  参考号

• 批处理id仅分配给一个交易存款明细

有一个用例，其中

交易存款细分

可能具有

参考号

或

批次id

，具体取决于支付处理者类型（类型1-参考号，类型2-批次id）。我不确定如何处理这个案件，但我正在考虑以下选项：

添加两个表

TransactionDepositBatch

和

TransactionDepositReference

，将

transaction\u deposit\u id

作为外键，在第一个表上添加

batch\u id

，在后一个表上添加

reference\u number

：

将

参考号

和

批处理id

列保留在

TransactionDepositorBreakdown

表中，并根据支付处理者的类型始终保留其中一列

null

注意：可能需要在

TransactionDepositBreakdown

表中添加另一列，例如

卡类型

，仅当支付处理器类型为1时，才会为其分配值

通过考虑上述注意事项，第一个选项是否是处理此问题的正确方法

---

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

这些关系很难在关系数据库中建模。不同的数据库具有不同的功能，因此有些数据库可能具有可应用于此问题的扩展（例如Postgres对表继承的支持）

你的情况很简单，只有两种选择。在这种情况下，我会选择第一个选项，原因很简单：它允许您轻松地使用声明的外键关系设计数据模型。缺点是，两个外键都需要空间，即使其中一个将为

NULL

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

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