与单列上的复合外键的关系

发布于 2025-01-07 03:50:09 字数 506 浏览 0 评论 0原文

我已向表中添加了一个“版本”列,该列需要成为表主键的一部分,但我与不包含版本的表有外键关系。 (也不应该)我确信我会得到至少一个答案来解释为什么这是不可能的,我明白为什么我不能在这里建立一种关系。我正在寻找一种优雅/无痛的方法来解决它。我需要的行为是主表可以添加版本,而“其他表”仍然链接到所有版本。这实际上是一种没有连接表的多对多关系。 (然而,实际上,给定键的主表的一个“版本”在任何给定时间都是活动的。)我计划使用检查约束和触发器的组合来强制我自己的引用完整性......但是有更好的方法吗?谢谢

表格

TableID (uniqueidentifier) - PRIMARY KEY
Version (int) - PRIMARY KEY
...

其他表格

OtherTableID (int) - PRIMARY KEY
TableID (uniqueidentifier)
...

I've added a 'version' column to a table that needs to be part of the table's primary key, but I've got a foreign key relationships to tables that don't contain the version. (And shouldn't) I'm sure I'm going to get at least one answer explaining why this isn't possible, I get why I can't create a relationship here. I'm looking for an elegent/painless way around it. The behavior I need is that the main table can add versions while the 'other table' remains linked to all of them. This is effectively a many-to-many relationship without a join table. (However in practice only one 'version' of the main table for a given key is active at any given time.) I plan to enforce my own referencial integrity using a mix of check constraints and triggers...but is there a better way? Thanks

TABLE

TableID (uniqueidentifier) - PRIMARY KEY
Version (int) - PRIMARY KEY
...

OTHERTABLE

OtherTableID (int) - PRIMARY KEY
TableID (uniqueidentifier)
...

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

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

发布评论

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

评论(4

欲拥i 2025-01-14 03:50:09

我认为最好将 TABLE 分成两个表:一个包含永远不会更改的数据(可能只是 ID 本身),另一个包含需要版本控制的数据。 OTHERTABLE 将有第一个表的外键。

(我应该提到的是,我们在工作中使用了这种方法,有时会导致烦人的复杂性,特别是当我们想要改变对哪些字段需要版本控制的想法时。这确实不完美。但其他方法往往会甚至导致更大问题。)

I think it would be better to split TABLE into two tables: one with the data that never change (which may just be the ID itself) and one with the data that need to be versioned. OTHERTABLE will have a foreign key to the first one.

(I should mention that we've used this approach where I work, and it's sometimes caused annoying complications, especially when we've wanted to change our minds about which fields need to be versioned. It's really not perfect. But other approaches tend to result in even bigger problems.)

再见回来 2025-01-14 03:50:09

如果我正确理解你的规格:

Parent
======
ParentID (uniqueidentifier) - PRIMARY KEY
...


OtherTable
==========
OtherTableID (int) - PRIMARY KEY
ParentID (int) -  FOREIGN KEY
...

ParentVersion
=============
ParentID (int) - PRIMARY KEY FOREIGN KEY
Version (int) - PRIMARY KEY

如果你想要每个父级都有一个活动版本,那么还有一张表:

ParentActiveVersion
=============
ParentID (int) - PRIMARY KEY 
Version (int) 
FOREIGN KEY (ParentID, Version)
  REFERENCES ParentVersion(ParentID, Version)

If I understand correctly your specs:

Parent
======
ParentID (uniqueidentifier) - PRIMARY KEY
...


OtherTable
==========
OtherTableID (int) - PRIMARY KEY
ParentID (int) -  FOREIGN KEY
...

ParentVersion
=============
ParentID (int) - PRIMARY KEY FOREIGN KEY
Version (int) - PRIMARY KEY

And if you want an active version per Parent, one more table:

ParentActiveVersion
=============
ParentID (int) - PRIMARY KEY 
Version (int) 
FOREIGN KEY (ParentID, Version)
  REFERENCES ParentVersion(ParentID, Version)
家住魔仙堡 2025-01-14 03:50:09

免责声明:以下内容适用于 SQL Server。我对其他 RDBMS 没有任何声明。

不要将其作为 PK 的一部分,只需在这两个字段上添加 UNIQUE INDEX 以强制唯一性:

CREATE UNIQUE INDEX ix_MyIndexName ON TABLE(TableID, Version)

您不需要触摸现有的键,但它会将重复的值保留在表之外。

如果您决定同时引用这两个字段(并且您正在使用 SQL Server),那么您也可以根据需要使用唯一索引作为外键的目标。

Disclaimer: Following is valid for SQL Server. I make no claims about other RDBMS.

Don't make it part of the PK, just add a UNIQUE INDEX on those two fields to enforce uniqueness:

CREATE UNIQUE INDEX ix_MyIndexName ON TABLE(TableID, Version)

You won't need to touch existing keys but it'll keep duplicate values out of the table.

If you decide down the road that you want to reference both these fields at once (and you are using SQL Server), then you can use a unique index as a target for a foreign key as well if needed.

獨角戲 2025-01-14 03:50:09

有点混乱,但这里的任何内容都会 - 基于 @ypercube 的评论 - 其他表是否都不是为了引用版本 1 而构建的(使用计算列强制 1 出现在每个表的列中)

Slightly kludgy, but anything here will be - based on @ypercube's comment - could the other tables not all be built to reference version 1 (using a computed column to force the 1 to appear in a column in each of those tables)

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