Database 价目表的数据库表结构

我有大约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 

---

谢谢你的评论。

我曾经走过这条路，并为此感到遗憾

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

我遇到的问题是，业务发生了变化，突然我要处理更多的组合，行的数量急剧增加，大大降低了查询速度。另一个问题是使数据保持最新—我的“超级”表是在单独的表发生更改时从这些表中计算出来的

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

我处理的数据几乎和你的完全一样，只是我只有3个

---

表：我有可用性、定价和利润。事实上，这3个是不相关的，因此日期范围从未对齐，在大表中有许多人工行。

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

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

如果您的使用模式一次只关注一张表，我会说“别管它了”。也就是说，如果它没有坏，就不要改变。如果您的使用涉及对一种类型的记录的多个更新，我倾向于将它们放在单独的表中（因此锁定一种类型的值不会阻止对其他类型的查询）

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

---

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

好吧，在我的例子中，所有数据都是相关的，几乎每个表中每天都有一个记录，在最后我进行了连接，结果几乎是相同的大表，但有一些where条件减小了该大小。类似于SELECT*FROM days LEFT JOIN rates.start_date>=day AND rates.end_date=day AND availability.end_date的内容在这种情况下，我会将表设计更改为具有单个日期列，而不是范围。即使这意味着连续几天重复数据，连接速度也会快得多，因为连接是在简单的equals比较中完成的，而不是在between匹配中完成的，特别是如果在date列上放置索引。这将使您的数据模型保持正常，并仍然提供出色的性能。感谢您的评论，我决定进行重组。