數據庫設計（許多不同項目的列表，自定義字段）

Question

我正在處理一個項目，您可以使用各種項目。它不重要，這是我擔心的數據庫設計。如果有人能夠給我一些見解，我應該如何爲此創建數據庫的佈局，或者只是指向正確的方向，我會非常感激。

在一個列表中的各種項目
想象一下，您有物品清單。您可以擁有CD列表，DVD列表和書籍列表。這將轉換爲1列表中包含數據庫術語中的許多項目，並且項目行中的列表的標識爲。
但是，如果你想要列出所有與超級馬里奧有關的東西，包含配樂DVD，恐怖的真人電影和一些基於水管工生活的小說小說的名單。
我突然意識到，當我繪製出我的數據庫時，屬於同一列表的這些項目不能在同一個表格中，因爲它們都有不同的列以支持藝術家/專輯名稱，導演/電影名稱，作者/小說標題等等。我不可能在一張巨大的桌子上放一張。
最重要的是，我想在我的數據庫中擁有電影原聲專輯的曲目標題和影片的演員。如果我只有CD，我可以很容易地將一張album_track-table附加到我的項目表中，但是我不能將各種不同的表格附加到我的項目表中，因爲如果我的表現不夠好想要獲得所有項目的詳細信息，並列出某個清單。該程序將不得不搜索所有附表中列出的參考，即使該列表不包含任何書籍，乙烯基，漫畫，電視系列，植物，傢俱等......

我現在所擁有的是以下佈局（但我無法想象這是做到這一點的最佳方式）：

t_list (id) --> t_item (id, id_list, image) 

t_item --> t_cd (id, id_item, artist, title) 
t_item --> t_dvd (id, id_item, director, title) 
t_item --> … 

t_cd --> t_cd_track (id, id_cd, track_title, length) 
t_dvd --> t_dvd_actors (id, id_dvd, actor_name, image) 
… 

自定義列
現在，假設將這些項目添加到CD列表，你必須根據表t_cd（藝術家，專輯標題，流派，...）中的列，一個帶有輸入字段的表單。我希望能夠爲專輯的平均價格添加自定義輸入字段。
這是爲特定用戶設置的某個列表。這不是在物品層面上設置的，因爲這意味着它會被添加到每個人的形式。我只想將該字段添加到我自己的CD列表中。
但是，它仍然需要與項目相關，因爲該值需要填入數據庫中。

我想是這樣的：

t_list (id) --> t_extra_field (id, description, id_list) 
t_extra_field --> t_field_value (id, id_extra_field, value) 

但我不能完全肯定在哪裏我的數據庫方案附加此。

難道這種結構也可以解答我以前的問題嗎？ （t_field --> t_field_value）如果是這樣，我也不知道該在哪裏附加。也許要列出，就像我在上面的例子中所建議的那樣？
這意味着某個項目的所有詳細信息都位於一個表格中，但根據來自附加到項目的另一個表格的某種類別ID（而不是單個記錄）的價值。這將是一個有很多記錄的表格，這再次提出了我的問題：這對性能不是不好。

我真誠地希望有人能給我一些見解。

Answer 1

完全通用的數據庫可能是個壞主意 - 通常意味着您必須在應用程序級別完全實施數據一致性。當你想在運行時避免DDL時，這可能是高度「非類型化」或「易失性」數據的理由，但這裏描述的數據看起來「足夠類型化」以適應更傳統的數據庫設計。

你的描述來看，你需要一些與此類似：

的符號表示「類別」（又名繼承，子類型，概括層次等）。

對於我們確切知道項目應該如何連接的具體情況，我們可以直接通過特定子類型之間的鏈接（aka.junction）表進行建模，例如TRACK表。

另外，我們可以通過GROUP和GROUP_ITEM對不同種類的物品進行分組（所以，可以在相同的GROUP_ID下將馬里奧音軌，電影和書籍組合在一起）。

藝術家也以相當一般的方式處理，因此我們可以很容易地表示（例如）同一人寫歌和書的情況。

---

至於東西，如「均價專輯」，最好你不應該將它們存儲在所有 - 在需要的時候，你應該計算它們，基於現有的數據，所以一個徹頭徹尾的可能性日期結果被消除。

如果這成爲問題的表現明智，或者：

• 它做定期，緩存結果，並與有些外最新結果住。

• 無論何時數據被修改（通過觸發器），都會緩存結果，但要非常小心地執行，以避免在併發環境中出現異常。

  例如...

  SELECT AVG(PRICE) FROM TABLE1; 
  INSERT TABLE2 (AVERAGE_PRICE) VALUES (result_of_the_previous_query); 
  

  ...幾乎可以肯定是不安全的，但根據即使是DBMS ...

  INSERT TABLE2 (AVERAGE_PRICE) VALUES (SELECT AVG(PRICE) FROM TABLE1); 
  

  ...可能不是沒有適當的完全安全鎖定。你需要了解你的DBMS的事務隔離和鎖定。

  在計算平均值的具體情況下，您可能會考慮其他技巧，例如分別通過每個INSERT/UPDATE/DELETE通過觸發器遞增/遞減COUNT和加/減SUM價格，然後即時計算AVG。 SQL保證諸如UPDATE MY_COUNT = MY_COUNT + 1之類的東西將是「原子」的。