Question

我喜欢大约10个表，其中记录包含日期范围，某些值属于日期范围。

每张桌子都有一些含义。

例如

费率

    start_date DATE
    end_date DATE
    price DOUBLE

可用性

    start_date DATE
    end_date DATE 
    availability INT

然后是表日期

     day DATE

未来2年的每一天的日期。

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

我一直在考虑创建一个包含每天所有10个表数据的大表，但最终表将有大约1.5M - 2M的记录。

从测试开始，在此表中搜索似乎更快（0.2秒而不是大约1秒）而不是连接表并搜索连接结果。

有没有任何真正的理由为什么有一个包含那么多记录的表应该是个坏主意？

决赛桌看起来像

    day DATE 
    price DOUBLE 
    availability INT

感谢您的评论。

Answer 1

我曾经走过这条路并后悔。

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

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

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

我所处理的数据与你的数据几乎完全相同，只有我只有3 表：我有可用性，定价和保证金。事实是，这3个是不相关的，所以日期范围从未对齐，在大表中租用了大量的人工行。

Answer 2

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

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

如果你的使用模式一次集中在一张桌子上，我很想说“留下足够好”。也就是说，如果没有破坏，不要做出改变。如果您的使用涉及对一种类型的记录的多次更新，我倾向于将它们保留在单独的表中（因此锁定一种类型的值不会阻止对其他类型的查询）。

但是，您的使用表明您正在组合表格。如果是这样，我认为每件物品每天排成一排是有道理的。如果您一次连续几天，您可能会发现在基础表中有不同的日子会大大简化您的查询。而且，如果您的查询专注于特定的时间范围，您建议的结构将保留缓存中的相关数据，为更好的性能提供空间。

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