0

私はいくつかのテーブルを持っています：

  • テーブルASKidask
  • テーブルPREFERENCESwith idpref、、fk_idaskfk_idstructure
  • テーブルSTRUCTUREwithidstructure

idとの間のすべての制約と、テーブルPREFERENCES（ 、 ）fk_idの一意のインデックスを使用します。fk_idaskfk_idstructure

問題は、PREFERENCESに2つの行がある場合です。

`IDPREF`   `FK_IDASK`   `FK_IDSTRUCTURE`  
 1          1            1  
 2          1            2

設定間の2つの構造を反転（切り替え？）したい場合

`IDPREF`   `FK_IDASK`   `FK_IDSTRUCTURE`  
 1          1            **2**
 2          1            **1**

最初の更新では、同じ構造の同じ質問に対して2つの設定が行われるため、との間FK_IDASKの一意のインデックスが分割されます。FK_IDSTRUCTURE

これを防ぐために、関数deleteAndResaveを作成します。これにより、今のところ問題が解決します。

しかし、今度はとでASSIGNATIONテーブルが到着しidassignationますfk_idpref。

ここで、ASSIGNATIONによってリンクされたプリファレンスを削除すると、制約が解除されます。

私はすでに回避策を見つけましたが、醜いです。この問題にはいくつかの正しい解決策がありますか？

答えてくれてありがとう！

ps。私の悪い英語でごめんなさい:(

4

2 に答える 2

1

あなたはこれを試すことができます：

UPDATE
    PREFERENCES
SET
    FK_IDSTRUCTURE = 3 - FK_IDSTRUCTURE

現在、1回で実行されるため、「ACID」の「C」（一貫性）は、外部キーと一意性が「中」に処理されることを意味しますが、前後は問題ありません。

より複雑なものについては、CASEステートメントを使用してステートメントをポン引きすることができます

UPDATE
    PREFERENCES
SET
    FK_IDSTRUCTURE = CASE FK_IDSTRUCTURE 
        WHEN 2 THEN 1 WHEN 1 THEN 2 ELSE FK_IDSTRUCTURE END
于 2009-05-25T12:03:25.097 に答える
-1

テーブル インデックスと分割の間で 2 つの構造を逆さまにします。

とにかく、あなたの外部キーが間違った方向を指していると思います。外部キーが割り当てられていて、設定を指しているようです。

外部キーは、設定と REFERENCE 割り当てにある必要があります。

もう 1 つのオプションは、外部キーの ON DELETE CASCADE オプションを検討することです。これは、参照されたテーブルの行を削除すると、データベース エンジンが外部キー テーブルの関連する行を自動的に削除することを意味します。

よく使用されるもう 1 つのオプションは、行を保持し、非アクティブとしてマークすることです。これは、「アクティブ ビット」列を追加することで実行できます。クエリを実行するとき、非アクティブとしてマークされた行を除外します。

于 2009-05-25T10:44:11.013 に答える