Question

我有许多不同的消息类型（比方说20）我需要根据日期和类型选择SELECT，其方式如下：

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

不同类型的消息共有很少的列（日期是最重要的），但我总是需要“一次性”获取所有类型的注释，按日期排序。消息具有自引用以允许线程对话。消息将始终为一种类型，并且只有一种类型。

因为我在存档中有5.000.000条消息，并且对话中的消息很少超过50条，所以我需要能够按日期或会话标识符进行有效选择。因此，我有一个“所有消息的母亲”-table和多个额外的表，它们与消息表有1 .. 0-1的关系：

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

接下来是我的问题： 您通常如何指定这些类型的表之间的关系？加入表中的（dis）优点是什么？以下方式：

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个可选列的感觉很脏，其中（仅）一列必须有一个值才能指定消息的类型。

另一方面，改为使用“类型”枚举列，并使用它来手动推断要查找其他信息的表也感觉不对 - 并且可能会导致大多数ORM中的大量工作

那么这本书对这些类型的结构有何看法？那天我有200种不同类型的消息呢？

Answer 1

恕我直言：任何时候你都必须改变你的数据库，因为你已经添加了一个新的“类型”的东西，正如他们所说，做错了。我唯一一次对这种类型的面向列的表感到满意的是，如果它刚好在生成报告之前就已经完成了。或者，或许，在流程结束时完成，以便为可能想要生成自己的查询的非技术用户轻松工作。

具有5到1千万行的正确索引和规范化表结构应该仍然可以正常运行。

数据库设计：引用多个1到0..1的关系

1 个答案: