我有一个很大的疑问。
让我们以公司订单的数据库为例。
假设这家公司每月生产大约2000个订单，因此，每年大约24K订单，他们不想删除任何订单，即使它已经5年了（嘿，这是一个例子，数字不要什么都不是。）
在具有良好的数据库查询速度的意义上，它最好只有一个表，或者每年表更快会更快？
我的想法是每年为订单创建一个新表，称为orders_2008，orders_2009等。
加速数据库查询可能是一个好主意吗？
通常使用的数据是当年的数据，因此线路越少越好。 显然，当我同时搜索所有订单表时，这会产生问题，因为我是否应该运行一些复杂的UNION ..但这种情况在正常活动中非常罕见。
我认为最好有一个应用程序，95％的查询速度快，剩下的有点慢，而不是总是很慢的应用程序。
我的实际数据库在130个表上，我的应用程序的新版本应该有大约200-220个表...其中大约40％将每年复制。
有什么建议吗？
编辑：RDBMS可能是Postgresql，也许（希望不是）Mysql
答案 0 :(得分：12)
较小的表格更快。周期。
如果您的历史记录很少使用，那么将历史记录放入其他表格会更快。
这就是数据仓库的意义 - 将运营数据与历史数据分开。
您可以运行定期提取从操作和加载到历史。保留所有数据，它只是隔离。
答案 1 :(得分：7)
在您担心查询速度之前，请考虑成本。
如果将代码拆分为单独的代码，则必须具有处理它的代码。你写的每一段代码都有可能出错。你要求你的代码是错误的，而牺牲了一些无法测量和想象的性能胜利。
还要考虑机器时间与程序员时间的成本。
答案 2 :(得分：3)
如果正确使用索引，则可能无需将其拆分为多个表。大多数现代数据库都会优化访问。
您可能考虑的另一个选择是为当前年份提供一个表格，并在最后将数据附加到另一个表格中，该表格包含前几年的所有数据。 ？
答案 3 :(得分：2)
我不会按年分割表格。
相反，我会每年将数据存档到报告数据库，并在需要时使用它。
或者你可以在驱动器之间对数据进行分区，从而保持性能，但我不确定在postgresql中这是否可行。
答案 4 :(得分：2)
对于您正在寻找的数据量，分割数据似乎很难获得很少的收益。 Postgres可以进行分区，但精细的手册[1]表示，根据经验，您应该只考虑超出服务器物理内存的表。根据我的经验，这至少有一百万行。
答案 5 :(得分：0)
我同意较小的表更快。但是，如果将单个实体拆分为多个表是有意义的，那么这取决于您的业务逻辑。如果您需要大量代码来管理所有表，那么它可能不是一个好主意。
它还取决于数据库您可以使用哪种逻辑来解决此问题。 In Oracle a table can be partitioned（以年为例）。数据存储在不同的表空间中，这样可以更快地解决（因为我假设一年的所有数据都存储在一起）
索引会加快速度，但如果数据分散在整个磁盘上，则需要加载块读取，这会使速度变慢。
答案 6 :(得分：0)
考虑在时间片中对表进行分区。对于类似于日志的表格情况，分区很有用，其中没有外键指向表格。