數據庫設計：引用多個1到0..1的關係

Question

我有許多不同的消息類型（比如說20），我需要根據他們的日期和他們的類型，按照以下方式進行選擇

即... WHERE date BETWEEN [fromDate] AND [toDate] AND type = [0 - 20 different types]

不同類型的信息的共同點（日期是最重要的）非常少列，但我會永遠需要「一氣呵成」來獲取各種意見，按日期排序。消息有一個自我引用來允許線程化對話。消息將始終是一種類型，並且只有一種類型。

因爲我在檔案中有5.000.000條消息，很少有超過50條消息在對話中，所以我需要能夠有效地按日期或會話標識符進行選擇。 所以我有有一個1 .. 0-1關係到信息表 - 表和多個額外的表一單「的所有郵件的母親」：

messages: [id, date, parent_id (nullable), ... ] 
msgs_type1: [col1, col2, col3, col4, ...] 
msgs_type2: [col1, col2, col3, col4, ...] 

然後我的問題是： 你通常如何指定關係這些類型的表之間？例如在表格中加入表格的（缺點）優點是什麼？以下幾種方式：

messages: [id, date, parent_id (null), **msg_type_1 (null), msg_type_2 (null)**, ...] 
msgs_type1: [col1, col2, col3, col4] 
msgs_type2: [col1, col2, col3, col4] 
... 

（可選的關係在消息中指定）

messages: [id, date, **type**, parent_id (null)] 
msgs_type1: [**message_id**, col1, col2, col3, col4] 
msgs_type2: [**message_id**, col1, col2, col3, col4] 
... 

（在msgs_type表指定強制的關係，在消息中指定的查找表）

在一個漢斯，感覺髒有20個可選列，其中（僅）一列必須具有值才能指定消息的類型。另一方面，改爲使用「type」枚舉列，並使用它來手動推斷要查找哪些表的附加信息也會感覺錯誤 - 並且可能會導致在大多數情況下使用的大量痛苦奧姆斯。

那麼這本書對這些類型的結構有何評論？那天我有200種不同類型的信息呢？

Answer 1

恕我直言：任何時候你在一個位置，你將不得不改變數據庫，因爲你已經添加的「東西」新「型」你是，正如他們所說，這樣做是錯誤。我唯一能夠對這種類型的面向列的表格感到滿意的是，它是否剛剛完成，比如正在生成報告。或者，也許是在流程結束時完成的，以減輕可能想要生成自己的查詢的非技術用戶的工作。

具有5至1000萬行的正確索引和規範化表結構仍應該可以很好地執行。