数据库设计：引用多个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万行的正确索引和规范化表结构仍应该可以很好地执行。