价目表数据库表结构

Question

我有大约10个表，其中有日期范围的记录和属于日期范围的一些值。

每个表都有一定的含义。

例如

费率

    start_date DATE
    end_date DATE
    price DOUBLE 

可用性

    start_date DATE
    end_date DATE 
    availability INT 

然后是表日期

     day DATE 

哪里是未来两年的每一天的日期。

最终结果是将这10个表连接到dates表。查询需要更长的时间，因为还有一些其他的连接和子查询。

我一直在考虑创建一个更大的表，其中包含每天所有10个表的数据，但最终的表将有大约150万-200万条记录。

从测试来看，在这个表中搜索似乎更快(0.2秒，而不是大约1秒)，而不是连接表和在连接结果中搜索。

有没有什么真正的理由让一个表包含这么多记录是不好的呢？

最后的表将如下所示

    day DATE 
    price DOUBLE 
    availability INT 

感谢您的评论。

Answer 1

这是一个复杂的问题。答案在很大程度上取决于使用模式。据推测，大多数值并不是每天都会改变。因此，您可以极大地增加数据库的大小。

另一方面，诸如可用性之类的东西可能每天都会发生变化，因此您的数据库中已经有一个很大的表。

如果你的使用模式一次只关注一个表，我会忍不住说“别管它了”。也就是说，如果它没有损坏，就不要进行更改。如果您的使用涉及对一种记录类型的多次更新，我倾向于将它们放在单独的表中(这样锁定一种类型的值不会阻塞对其他类型的查询)。

但是，您的用法表明您正在合并这些表。如果是这样的话，我认为将它们放在每个项目每天的一行中是有意义的。如果您一次获得连续的日期，您可能会发现在基础表中有单独的日期会大大简化您的查询。而且，如果您的查询集中在特定的时间范围内，那么您提出的结构将在缓存中保留相关数据，从而为更好的性能提供空间。

我很欣赏波西米亚人说的话。但是，您已经达到了最低级别的粒度，并且看到它对您有效。我认为你应该继续进行重组。

Answer 2

我曾经走过这条路，并为此感到后悔。

您有一个数百万行的投影，这一事实告诉我，一个表中的日期与另一个表中的日期不一致，这会导致为某些属性创建额外的边界，因为在一个表中，所有属性必须共享相同的边界。

我遇到的问题是，业务发生了变化，我突然有了更多的组合要处理，行数激增，大大减慢了查询速度。另一个问题是保持数据最新-我的“超级”表是从单独的表中计算出来的，当它们发生变化时。

我发现将它们分开并将逻辑转移到应用层对我很有效。

我处理的数据与您的数据几乎完全相同，只是我只有3个表:可用性、定价和保证金。事实是，这3个是不相关的，所以日期范围从不对齐，租借给大表中的许多人工行。