規範化關係數據庫時，是否應該將多個“類型”表合併為一個？
在對我的網站的內容、功能和設計進行重大更改之前（我將重構所有內容，幾乎完全重寫），我正在設置一個新的 PostgreSQL 數據庫來保存以前在 MySQL 數據庫中的所有數據。我還有一個高度定制的 WordPress 部落格，我將把它移到這個網站上，有效地合併這兩個網站。除了網站的前端內容外，還有很多其他資訊我儲存在數據庫中供我自己使用，例如客戶資訊、銷售歷史、發票、活動收入等。我正在採取很多時間仔細考慮並嘗試正確地重新設計數據庫，同時考慮到數據完整性和性能。
前端網站將有許多不同的“內容”類型：頁面、活動/演出、多媒體樣本、樂譜/圖表（其中一些將在網站上以 PDF 格式出售）、部落格文章等。
我所做的更改之一是我儲存場地/地點的方式。我曾經有一個引用“場地類型”表的“場地”表以及一個引用“州/省”表的“城市”表，該表引用了一個“國家”表。這些資訊大部分被“事件”使用，但後來我添加了需要引用城市表的客戶資訊。此外，我所有的部落格文章都帶有地理標記，因此他們也需要參考這些地方。由於所有的表都有一個非常相似的模式，我所做的是創建一個帶有“id”和“parent_id”列的新“places”表，以便可以以分層方式儲存位置。我也有一個“places_type” 表，以便我可以強制每行的 parent_id 必須是比地方本身更高的層次類型。（例如，一個城市可以將州或國家作為其父類型，但一個城市不能將餐廳作為其父類型。）
為此，我創建了許多具有完全相同架構（id、parent_id、名稱）的其他表來保存層次結構中其他內容的“類型”。流派、支付方式、圖表類型、事件類型、媒體類型、發票類型等。
由於所有表都具有完全相同的架構，將所有這些表組合成一個“類型”表並在表中添加一個“類別”欄位會更好嗎？
我認為管理一個“類型”表比管理十一個類似的表要容易得多。我已經計算出這個“類型”表現在只能容納大約 60 行左右。
我想知道在數據庫設計方面這種事情的最佳實踐是什麼？數據的檢索頻率將遠高於更新/添加的頻率。
同時，由於這個“類型”表將包含所有類型的所有內容，因此需要（通過視圖）多次連接到多個表。例如，要檢索事件資訊，我已經將“事件”表連接到“地點”、“藝術家”和“媒體”表，但還需要將這些表連接到“類型”表以獲取事件類型，地點類型、藝術家類型和媒體類型。那麼最好將類型表分開，還是將它們合併為一個？為什麼？
我會為每種類型選擇單獨的表格。由於行數如此之少，無論哪種方式，性能都不會成為考慮因素。單獨的表格每張只有一兩頁。對於組合表也是如此。
無論哪種方式，您都必須加入“類型”表才能完成您的視圖。在這個抽象級別上插入很少見，因此無論哪種方式，鎖定都不太可能成為問題。
不過，對我來說，擁有不同的表可以將邏輯上不同的項目分開，這是一種更簡潔的設計。
將有許多不同的表，它們與某種類型的表有關係。如果有許多不同類型的表，則外鍵關係是自記錄的並且可以通過 DRI 強制執行。例如，對於一個組合表，很難使用 DRI 說“Venue.TypeID 來自 Type.TypeID，但前提是 Type.Category = ‘V’”。這種關係的補充方面——“Type.TypeID with Type.Category = ‘V’ can only be used in the Venue table”——在我所知道的任何 RDBMS 的 DRI 中也不支持。