处理历史记录的重复表是否是一种不良做法？

Question

我需要开发一个移动应用程序，用户可以在其中直观地看到本周的预订时间表（哪些时间可用，哪些可用）。我的方法是使用以下 table:

CREATE TABLE Reservations (
    Id serial  NOT NULL,
    BookDate timestamp  NOT NULL,
    SessionDate timestamp  NOT NULL,
    FinishDate  NOT NULL,
    User_Id int  NOT NULL,
    Status varchar(30)  NOT NULL,
    CONSTRAINT Reservation_pk PRIMARY KEY (Id)
);

从那里，我的后端将识别我们当前所在的那一周，并查询本周星期一和星期日之间的所有预订。这将在稍后由移动应用程序以很好的方式显示。

问题是我意识到预订量在不断增加，移动应用程序唯一需要显示的是本周。我不想从 300 万行中查询并执行所有这些过滤器（以查看预订是否已取消或是否来自过去的日期）只显示当前周。

所以我想也许我可以有一个预订 table 只处理当前一周的预订，在这周结束后，该行将从那里删除并转到预订历史记录 table（将具有相同的结构）。

目前，这对我来说似乎是一个很好的解决方案，但我不知道具有更高数据库设计技能的人是否会认为这是一个很好的做法。如果能听到有关此要求或我的方法的任何建议或评论，我将不胜感激。

Answer 1

一个 table 是您发现其他情况之前的必经之路。只需获取任何调用应用程序或进程来查询手头任务所需的天数。您可以在不同的日期添加索引以提高效率。如果你真的，真的运行遇到问题，你可以添加一个日期分区，但这只是将一组低效率换成另一组，所以你需要了解你在做什么。

处理历史记录的重复表是否是一种不良做法？

Are duplicate tables for history handling a bad practice?

database

database-design

database-schema

system-design