ListServ 数据库：统计表设计问题

Question

我这里有一些设计问题。我有自己的用 Python 编写的 ListServ 实现，它与 Postfix+Dovecot 系统一起工作以处理邮件，以及一个 PostgreSQL 数据库后端，用于确定以下大部分功能：

• listserv 上存在哪些列表（lists下图中的表格）
• 谁曾在 listserv 上被视为任何列表的成员。（下members图中的表格）
• 谁是列表的当前成员，以及：（listserv_membership下图中的表格，通过列表服务 ID 和成员 ID 将个人“成员”链接到他们所属的个人“列表”）
  • 他们可以发送到列表吗？（表格中的隐藏字段）
  • 他们可以接收发送到列表的消息吗？（表格中的隐藏字段）
• ListServ 统计 - 根据当前日期的时间戳，对于每个有活动的单独列表，每天的消息计数。（下listserv_stats表）

目前，数据库的结构是这样的（注意，我已经把我不打算关注的表中所有不相关的字段都去掉了，并保留了主键；相关表用三个标记旁边的白色星号，此图是使用 DataGrip 创建的）：

_{请不要因为图中的对角线箭头而大喊大叫——这个是作为一个快速而肮脏的图表完成的，而我在 Visio 中手工完成了一个很好的ERD，不幸的是我现在使用的计算机上没有}

我要问的具体表是listserv_stats这里的表，而不是数据库设计的其余部分。

现在，最初，我只担心每天跟踪统计数据，以及基于列表服务活动天数的“所有时间”非常粗略的每日平均值。我现在更关心其他统计数据，例如月平均值、本月至今平均值、年初至今平均值和年度平均值，因此我正在考虑重新设计以更好地适应此类搜索。

当前的表CREATE语句是这样的：

CREATE TABLE listserv_stats
(
    lsid INTEGER NOT NULL,
    datestamp DATE DEFAULT now() NOT NULL,
    msg_count INTEGER NOT NULL,
    CONSTRAINT listserv_stats_lsid_date_pk PRIMARY KEY (lsid, datestamp),
    CONSTRAINT listserv_stats_lists_lsid_fk FOREIGN KEY (lsid) REFERENCES lists (lsid)
);
COMMENT ON COLUMN listserv_stats.lsid IS 'ListServ ID';
COMMENT ON COLUMN listserv_stats.datestamp IS 'DateStamp';
COMMENT ON COLUMN listserv_stats.msg_count IS 'Message Count';

我正在考虑做的是扩展表格以替换datestamp列，如下所示。在我看来，这将使我能够在我的 Python 代码（可以将各个值重建为日期戳）中更好地处理月至今、月历史、年初至今和年度历史值：

CREATE TABLE listserv_stats
(
    lsid INTEGER NOT NULL,
    year INTEGER NOT NULL,
    month INTEGER NOT NULL,
    day INTEGER NOT NULL,
    msg_count INTEGER NOT NULL,
    CONSTRAINT listserv_stats_lsid_date_pk PRIMARY KEY (lsid, year, month, day),
    CONSTRAINT listserv_stats_lists_lsid_fk FOREIGN KEY (lsid) REFERENCES lists (lsid)
);
COMMENT ON COLUMN listserv_stats.lsid IS 'ListServ ID';
COMMENT ON COLUMN listserv_stats.year IS 'Date: Year';
COMMENT ON COLUMN listserv_stats.month IS 'Date: Month';
COMMENT ON COLUMN listserv_stats.day IS 'Date: Day';
COMMENT ON COLUMN listserv_stats.msg_count IS 'Message Count';

由此，我可以重构数据库中现有的预定义例程，以允许我的 Python 代码通过将整个日期作为值传递来调用“新日期记录”和“更新日期记录”函数。

我的问题是，这种设计更改是一个好主意，还是我可以使用我已有的原始“日期戳”表来实现所有功能？如果保留原始设计，我将不得不弄清楚如何构建例程以提供系统中那些特定日期范围的数据（我很可能会为此发布 SO）。

Answer 1

因此，在该网站的聊天室中，我被告知不要管我的表结构，而是使用视图或特定查询从时间戳中获取我需要的数据。

鉴于此，我决定不理会该表，并开始研究与 PostgreSQL（以及我信任的另一个组喜欢使用这些函数的 MSSQL）的日期交互函数，并开始将此类特定检查合并到预定义例程中，我已经设计了这个系统。

我在问题中遗漏的唯一一件事是，我的 Python 代码库仅通过我编写的预定义例程和函数与数据库交互，因此如果我可以正确配置数据库函数以正确处理数据，则视图就不太必要了。我的雷达上的具体日期范围。

感谢所有在聊天中直接向我发表评论的人，它帮助我重新构建了功能的初始设计，并在数据库端而不是 Python 端做了很多事情。