2

我有一张桌子

documents
(
    year int not null, 
    number int not null, 
    document_types_id int not null, 
    ...
)

主键是 year + number + document_types_id。

我认为更好的主键是 year + document_types_id + number。有没有办法在不删除和重新创建 PK 的情况下重新排序此组合（不是表中的列、PK 和 FK 组合），因为此 PK 在许多其他表中用作 FK。

谢谢。

4

4 回答 4

1

您必须先删除主键才能稍后更改它。否则，您会收到一条消息，即一张表上不能有两个主键。

但这没问题，只要做

Alter Table myTable NOCHECK Constraint All

然后随心所欲地改变你的桌子，然后做

Alter Table myTable CHECK Constraint ALL

你很好。

MySQL 中的等价物是：

SET FOREIGN_KEY_CHECKS = 0;

和

SET FOREIGN_KEY_CHECKS = 1;
于 2012-09-05T10:06:37.113 回答
1

您的外键引用您的主键，因此您的外键是 3 维的（年份 + 数字 + document_types_id）。如果您要摆脱一个维度，那么即使您尝试修改主键，您的约束也会告诉您无法摆脱给定的列，因此您应该先处理外键，然后才能修改你的主键。脚步：

  1. 将所有外键写入一个列表，以便您知道之前的外键。

  2. 摆脱所有引用主键的外键

  3. 修改/重新创建您的主键

  4. 根据新版本的主键重新创建外键。

于 2012-09-05T10:50:45.847 回答
0

如果在其他表上删除 FK 是一个问题，那么您可以按该顺序使用这些列创建一个非聚集索引并提供提示（WITH INDEX(ALTER TABLE 语法没有为ALTER CONSTRAINT语句留下范围。

于 2012-09-05T10:02:32.150 回答
0

不。在关系模型中，键中的属性没有有意义的排序。但在 SQL 中，有。外键的列与外键引用的主键或唯一键的列的对应关系是按序号位置，而不是按名称。

因此，键声明中的列的顺序是有意义的，如果当前有效地使用了该含义/顺序，那么您无法在不破坏当前使用的情况下更改它。

除了。该理论对关键属性/列的排序没有任何意义，这并非没有道理。与现有密钥相比，您认为“重新排序”密钥究竟“更好”的是什么？

于 2012-09-05T18:02:24.203 回答