PostgreSQL 13-通过参考支持分区

发布于 2025-01-22 19:38:48 字数 572 浏览 1 评论 0原文

我们在Oracle中设置了以下分区,我们需要迁移到PostgreSQL(版本13) -

CREATE TABLE A (
id number(10) not null,
name varchar2(100),
value varchar2(100),
createdat date
constraint a_pk primary key (id))
partition by range (createdat);

CREATE TABLE B (
id number(10) not null,
a_id number(10) not null,
....
....
constraint b_pk primary key (id),
constraint b_a_fk foreign key (a_id) references a (id) on delete cascade
) partition by reference (b_a_fk)

PostgreSQL中不支持逐个参考分区。任何人都可以建议替代方案在PostgreSQL中取得相同的成就。基本上,我们需要确保从两个表中删除旧分区时,表“ B”中的所有记录都应丢弃,以相对于“ A”中的相关记录。

We have the following partition set up in Oracle which we need to migrate to Postgresql (version 13)-

CREATE TABLE A (
id number(10) not null,
name varchar2(100),
value varchar2(100),
createdat date
constraint a_pk primary key (id))
partition by range (createdat);

CREATE TABLE B (
id number(10) not null,
a_id number(10) not null,
....
....
constraint b_pk primary key (id),
constraint b_a_fk foreign key (a_id) references a (id) on delete cascade
) partition by reference (b_a_fk)

Partition by reference is not supported in Postgresql. Could anyone please advise the alternatives to achieve the same in Postgresql. Basically we need to ensure that when older partitions are dropped from both tables, all records in table "B" should get dropped corresponding to related records in "A".

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

烟─花易冷 2025-01-29 19:38:48

您必须在b中保留创建的冗余副本,以便可以将其用作分区密钥。

为了确保相关日期相同,请考虑以下想法:

  • 您不能将id作为主要密钥,因为它不包含分区键create> create> createat

  • ,因此请使用(id,createat)>作为a

    的主要键

  • 的主要键,然后您可以在on 上定义外键(a_id,createat),它将自动保证相关日期相同


,该解决方案不是完美的 - 特别是,您不能保证ID的唯一性。但是我认为这是您能拥有的最好的。

You have to keep a redundant copy of createdat in b so that you can use it as partitioning key.

To make sure that the related dates are the same, consider the following idea:

  • you cannot have id as a primary key, since it does not contain the partitioning key createdat

  • so instead use (id, createdat) as primary key of a

  • then you can define the foreign key on b on (a_id, createdat), which will automatically guarantee that the related dates are identical

Sure, that solution is not perfect – in particular, you cannot guarantee uniqueness of id. But I think it is the best you can have.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文