如何在關系數據庫設計中處理 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);