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 は他の多くのテーブルで FK として使用されているため、PK を削除および再作成せずに、この構成 (テーブル、PK および FK の組み合わせの列ではなく) を並べ替える方法はありますか。

ありがとう。

4

4 に答える 4

1

外部キーは主キーを参照しているため、外部キーは 3 次元 (年 + 番号 + document_types_id) です。ディメンションを削除する場合、主キーを変更しようとしても、指定された列を削除できないことが制約によって通知されるため、最初に外部キーを処理してから変更できますあなたの主キー。手順:

  1. すべての外部キーをリストに書き込んで、どれが以前の外部キーであったかを知ることができるようにします。

  2. 主キーを参照するすべての外部キーを取り除く

  3. 主キーを変更/再作成する

  4. 主キーの新しいバージョンに従って、外部キーを再作成します。

于 2012-09-05T10:50:45.847 に答える
1

後で変更するには、最初に主キーを削除する必要があります。そうしないと、1 つのテーブルに 2 つの主キーを設定できないというメッセージが表示されます。

しかし、それは問題ありません。

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 に答える
0

いいえ。リレーショナル モデルでは、キー内の属性に意味のある順序付けはありません。しかし、SQL にはあります。外部キーの列と、外部キーが参照する主キーまたは一意のキーの列との対応は、名前ではなく序数によるものです。

したがって、キー宣言内の列の順序は意味があり、その意味/順序が現在効果的に使用されている場合、現在の使用を中断せずに変更することはできません。

その上。理論が主要な属性/列の順序付けに意味を持たないことは、理由がないわけではありません。既存のものと比較して、「再注文された」キーで「より良い」ものは何だと思いますか?

于 2012-09-05T18:02:24.203 に答える
0

If dropping the FK on other tables is a problem, then you can create a non-clustered index with those columns in that order and provide hints (WITH INDEX(ALTER TABLE syntax leaves no scope for an ALTER CONSTRAINT statement.

于 2012-09-05T10:02:32.150 に答える