我有一个这样的 Postgres 表:
CREATE TABLE example_table_1
(
snap_date DATE NOT NULL, -- the official day the row items apply to (for reporting)
item_id VARCHAR(255) NOT NULL, -- the "pk" for each snap_date's data
created_at TIMESTAMP DEFAULT NOW() NOT NULL, -- when the row was inserted into the DB
updated_at TIMESTAMP DEFAULT NOW() NOT NULL, -- when the row was last updated
...other_columns
)
;
数据可能类似于:
snap_date | item_id |
---|---|
2023-03-07 | a_uniqueish_value_1 |
2023-03-07 | a_uniqueish_value_2 |
2023-03-06 | a_uniqueish_value_1 |
2023-03-05 | a_uniqueish_value_3 |
数据将每天加载,附加到当前数据。保留 180 天的历史记录,并且由于报告要求,必须通过与最新数据相同的界面进行查询。
item_id
和 snap_date
都构成一行的唯一键; item_id
可以出现在一个或多个 snap_date
中,并且可能会从任何未来 snap_date
的每日报告中消失(这意味着 item_id
可以在任何未来snap_date
中出现或消失)。
item_id
是通过对表中除 snap_date
之外的所有列进行哈希计算得出的。如果有更好的选择,我愿意改变这一点,但需要有一个“id”来识别跨天的相似行。
此表还与(结构类似的)表有外键关系,这些表也每天用
snap_date
更新。对于每天的报告,所有表格的快照日期都相同。对外关系在item_id
和snap_date
,目前。
我已经尝试将
snap_date
和 item_id
设置为复合主键,但我认为这对于我读过的其他帖子的性能来说并不理想。我可以将 item_id
和 snap_date
列散列到一个字段中,这 might 工作,但感觉很老套。
主要问题是:
item_id
和 snap_date
上的复合键在这种情况下是合适的,是否有使用单列作为 PK 的替代方案?