Postgresql
單表設計還是多表設計,記錄有明顯區別但一起查詢?
假設我有以下類型的重複數據(所有類型都會定期出現)。
- 文章(標題、摘要、文本、時間戳)
- 圖片(URL、標題、時間戳)
- 事件(開始日期、結束日期、標題、描述、位置)
正如數據的風格所暗示的那樣,我們可以將它們分別拆分為單獨的表
Post
、Image
和Event
。然而,對這些數據的大多數查詢屬於“時間線”類型(將給定時間範圍內的所有文章、圖像和事件返回給我,按時間排序),儘管也有一些查詢僅適用於單一類型。有人建議我們將所有三個組合到一個表中,並將唯一屬性編碼到一個
json
欄位中(我們使用的是 Postgres 9.3+),而不是使用UNION
三個表中的一個。所以根據那個模型,我們會有
- 資訊(類型、時間戳、屬性)
其中 Attributes 是一個 JSON 欄位,它將根據 Type 值具有不同的鍵。
這裡哪種方法更好?
PS 這是一個解釋問題的簡單範例,但實際上有接近 9 種不同“類型”的數據,並且唯一屬性的數量要大得多。將來我們可能還需要加入其中一個獨特的屬性(不確定 Postgres 是否支持這一點)。
我不會把它們都放在一起。即使您一起查詢它們,您的應用程序也可能會在每個文章中發布多個圖像或每個文章中發布多個事件或每個事件中發布多個文章。
在這種情況下,您將能夠節省空間。JSON 可能是一個好主意,但使用多個表會更好(鑑於索引)。通過這種方式,您可以提供可以改進查詢過程的索引。
另一個想法可能是使用排列。這意味著您有一個全域表,其中包含許多具有相同結構的不同類型。例如:
CREATE TABLE types( id int, type nvarchar(50), property1 int, property2 nvarchar(50) )
通過這種方式,您可以儲存一個
Type = 'Image'
包含property1
(訂單號)和property2
(路徑)的值。此外,您還可以舉辦一個活動,例如Type = 'Event'
將日期保存在 中property1
,並將名稱保存在property2
. 舉個例子。