我應該把這張大桌子分成三個小桌子嗎？

我正在設計一個 PostgreSQL 數據庫，其中將包含有關我的使用者上傳的照片的資訊。所有使用者都將擁有至少一張主照片和可選的一張或多張公共和/或私人照片。我的第一個架構如下：

user
----
id (PK)

photo
-----
id (PK)
user_id   (FK to user)
photo_id  (unique identifier such as "aK1q9")
type      ("main" or "other")
access    ("public" or "private")

執行最多的查詢是：

SELECT p.photo_id FROM photo p INNER JOIN user u ON p.user_id = u.id WHERE p.type = 'main' AND u.id = (some user id);

下一個最受歡迎的查詢將是：

SELECT p.photo_id FROM photo p INNER JOIN user u ON p.user_id = u.id WHERE p.type = 'other' AND p.access = 'public' AND u.id = (some user id);

我預見的問題是 Photo 表會隨著時間的推移變得非常大，因為它將包含所有使用者上傳的所有公共和私人照片。由於我最受歡迎的查詢只會查找主要的照片 ID，因此將我的照片表分成三個表是否更有意義？

main_photo
----------
id (PK)
user_id   (FK to user but in a one-to-one relationship to user)
photo_id

other_public_photo
------------------
id (PK)
user_id   (FK to user)
photo_id

other_private_photo
-------------------
id (PK)
user_id   (FK to user)
photo_id

我認為後一種模式會更可取，因為 1）每張照片的類型和訪問資訊都通過儲存位置明確說明，從而消除了我的查詢中的額外 AND；2）我的查詢會執行得更快，因為它們將針對三個較小的表之一而不是一個大表執行。從性能的角度來看，哪種方法是最佳方法？

謝謝。

我認為，這是一個設計問題，而不是數據庫技術。所以，我用目前正在研究的數據庫技術提供了答案。但是，您更喜歡使用偽來解釋它，所以在這裡您可以使用另一個答案。我可以去編輯另一個，我是故意離開的，這樣如果 SQL Server 的人訪問這個頁面，那麼他可能會欣賞它，我們永遠不知道！

表名：使用者

原因：要求始終將主照片與使用者相關聯，僅將主照片 ID 的引用與使用者記錄一起儲存是有意義的。

Columns
----------------
UserId (PK)
PrimaryPhotoId (FK to Photo table)

表名：照片

描述：只管理一個表會容易得多。如果您想儲存更多資訊，如工具提示、Alt 文本、圖像描述等，將來絕對可以擴展此表中的列。其他表不會受到干擾，並且絕對不需要更改.

Columns
----------------
PhotoId (PK)

表格名稱：UserPhoto

說明：此表格為您提供了建立一對多關係的靈活性。它還使用標誌（IsPrivate 列）標識每張照片是私人的還是公共的記錄。如果您希望限制每個使用者不應將同一張照片關聯兩次，那麼建議的複合唯一鍵是有意義的，否則您需要擴展唯一鍵但表格設計應保持不變。

Columns
----------------
UserPhotoId (PK, AutoIncrement)
UserId (FK to User table)       - Composite Unique Key
PhotoId (FK to Photo table)     - Composite Unique Key
IsPrivate (Bit Data type to store 0 or 1. 0 value represents for 'Public', 1 value represents for 'Private' photo)

引用自：https://dba.stackexchange.com/questions/117807