針對與人匹配的網站的數據庫設計

Question

我正在創建一個Facebook網絡應用程序，其功能與約會網站類似，可讓用戶在匹配的用戶中提供有關自己的信息以及有關其偏好的信息。

我創建這個數據庫，心裏有以下設計：

• 成員表：包含有關使用他們的FB ID作爲主鍵的用戶的信息。
• 首選項表：包含有關用戶所需首選項的信息。

將會有大約20個字段，用戶可以指定偏好，但所有這些字段都是可選的。我不確定構建我的「喜好」表和我的最佳方式目前有兩種思路：

解決方案1：使用Facebook ID的外鍵，並有可以匹配的每個字段的新列上。我可以看到的一個問題是，數據庫中會有大量「空」值用於沒有指定值的字段。

• 數據庫中的「空」值是否佔用空間或導致其他問題？

解決方案2：使用Facebook ID的外鍵了，但在接下來的兩列使用鍵值對的方法 - 這樣一列將包含一個ID爲用戶偏好和其他將包含它的價值。對於每個用戶的偏好，我會有一個結構記錄：「用戶ID」 - 「偏好ID」 - 「值」。

• 問題，這是有價值的，在「值」列的類型將取決於「偏愛ID」的內容欄

我的問題：

• 哪種方法更好？
• 這種Web應用程序是否有標準的模式解決方案？

Answer 1

正如您已經注意到的那樣，您正在尋找一種折中方案。你走哪條路取決於你的生產數據真的是什麼樣子。

只要列中使用可變長度數據，稀疏表中的空值佔用一點空間，但不是很大。十個零變量不是很長。十個空整數只有十個非空整數。

如果您在第二個解決方案中添加第三個由「偏好ID」鍵入的表「PreferableThings」，那麼您擁有的技術上並非大多數人避開的鍵值對或EAV。正如您所指出的那樣，難度在於，具有不同數據類型的首選項必須以常見編碼形式（通常是varchar）存儲。這解決了稀疏表格的問題，但它迫使您創建一些應用程序邏輯，以便從常用數據類型解碼爲適當的本機數據類型。您可以在「PreferablyThings」表中存儲執行此操作的規則。

然而，第二種方法的另一個優點是您可以對新的首選項的添加進行表驅動。通過解決方案1，您需要更改模式。