數據庫設計，減少join

Question

這是一個用於門票在線商店的數據庫（例如 Airbnb 體驗）

為商品（票），

有可用的日子（和時間）

在有空的日子，
- 可能有多種選擇（例如初級班、高級班）
- 有一個可以出售的數量（在多個選項之間共享）

表示這一點的一種方法是

Product
  name

Variant (Option)
  product

TimeSlot
  product
  date
  time
  quantity


TimeslotVariant
  variant
  timeslot

另一種方法如下。

我看到兩個主要區別，

• 第一個區別

  • 上圖：您需要加入TimeSlot以查找特定日期的變體。
  • 下圖：可以直接查詢TimeVariant

• 第二個區別

  • 上圖： [{date, time, [variant1, variant2], quantity}] （我認為客戶端應用程序更喜歡這個）
  • 下面： [{date, time, variant1}, {date, time, variant2}] + [{date, time, quantity}]

---

Product
  name

Variant (Option)
  product


TimeSlot
  product
  date
  time
  quantity

TimeVariant
  variant
  date
  time

我認為第一個選項更直觀（？）但我也認為額外的連接有時會很痛苦

我應該問自己什么問題（標准）來決定這兩者？

Answer 1

恕我直言，連接數可能不是您在設計關系數據庫時需要問自己的最重要問題。

最重要的問題是如何確保保護數據完整性。 您提供的第一個選項最好保持數據完整性，因此這是您應該使用 go 的選項。

如果連接是困擾您的問題，您始終可以使用視圖來“扁平化”數據。

但為什么第一個選項更好？ 因為TimeSlot表的主鍵（或至少是自然鍵）必須由product 、 date和time組成 - 而第二個選項不會在TimeVariant表中考慮產品。

您也可以將product添加到該表中，並且一些 DBA 會建議將其作為最佳選擇（那些將是反對使用代理鍵的 DBA） - 但就個人而言，即使我自己不是 DBA，我認為代理鍵有它的優點，其中一個正是你在這里所擁有的——你可以使用單列而不是三列來連接兩個表——這讓你的生活更輕松（並強制執行自然鍵的唯一性）表中沒有代理鍵的完整性問題）。

Answer 2

首先，您應該認為您想減少加盟費用嗎？ 如果是，那么您可以使用存儲在視圖中的展平數據。

第一個案例

在TimeslotVariant中，您添加了變體和時間段，只有通過查詢 TimeslotVariant 表，您才能獲得預期的數據。 在這種情況下，您的數據完整性還可以。

第二種情況

如果您將產品密鑰添加到您的 TimeslotVariant，那么僅顯示產品列表將達到目的，盡管時間和日期也會重新輸入。

我的建議是保留第一個案例並將展平數據存儲在視圖中。