複数のテーブルで同じ列を更新する方法

Question

同じSQLデータベース内の複数のテーブルで同じ列を更新する方法を知りたいが、これらのテーブルは主キーであるその列を介して相互に関連している他のテーブルのC＃で助けてください。

Answer 1

プライマリキーを変更するのは決して楽しいことではありません。多くの人がナチュラルキーよりもsyntheticを好む理由です。それを行うための単一ステートメントの標準SQL方法はありません。その代わりに、マスター表の行のコピーを新しい主キーでINSERTし、子表をUPDATEして新しい行を参照し、元の行をDELETEする必要があります。

Answer 2

あなたが望むものは、外部キー制約で指定できます。例：ここにチェックMySQL syntax。

このようなものは、あなたのsql-dialectでもうまくいくはずです。

[CONSTRAINT symbol] FOREIGN KEY [id] (index_col_name, ...) 
    REFERENCES tbl_name (index_col_name, ...) ON UPDATE CASCADE 

CREATE TABLE Parent(
    PID SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT, 
    Name VARCHAR(20), 
    PRIMARY KEY (PID) 
); 

CREATE TABLE Child(
    CID SMALLINT UNSIGNED NOT NULL PRIMARY KEY, 
    PID SMALLINT UNSIGNED NOT NULL, 
    FOREIGN KEY (PID) REFERENCES Parent (PID) 
    ON UPDATE CASCADE 
); 

INSERT INTO PARENT (Name) VALUES ('Joe'); 
INSERT INTO PARENT (Name) VALUES ('Max'); 
INSERT INTO Child (CID, PID) VALUES (1, 1); 
INSERT INTO Child (CID, PID) VALUES (2, 2); 

SELECT * FROM Parent; 
SELECT * FROM Child; 

Parent    Child 
+------+------+ +------+------+ 
| PID | Name | | CID | PID | 
+------+------+ +------+------+ 
| 1 | Joe | | 1 | 1 | 
+------+------+ +------+------+ 
| 2 | Max | | 2 | 2 | 
+------+------+ +------+------+ 

UPDATE Parent SET PID='5000' WHERE PID='1'; 
SELECT * FROM Parent; 
SELECT * FROM Child; 

Parent    Child 
+------+------+ +------+------+ 
| PID | Name | | CID | PID | 
+------+------+ +------+------+ 
| 5000 | Joe | | 1 | 5000 | 
+------+------+ +------+------+ 
| 2 | Max | | 2 | 2 | 
+------+------+ +------+------+ 

このサンプルでは、​​DB-Systemによって問題が発生する可能性があります。 DBシステムが、あるポイントで "AUTOINC Mode"になっているときにPIDがすでに割り当てられているかどうかをチェックしない場合、autoincremntの値は5000に達する可能性があります。自動増分が指定されている場合、DB-Systemが主キー列をどのように変更するかによって異なります。

Answer 3

質問に答えたいのは、ジッタの回答に記載されているカスケード更新による外部キーです。しかし、ほとんどの設計上の考慮事項のように、このような操作を実行するための根本的な必要性を分析して分析した場合、この質問をする必要はありません。

これは機能しますが、データベースエンティティの主キーが時間の経過とともに信頼できないことを意味します。また、データベースがカスケードを実行するために膨大な作業をしなければならない可能性があります。そのような更新を実行する際のロックが増え、ブロックする可能性が高くなります）。時間をかけて信頼性に関しては

、アカウント上で歴史的な残高を維持して倉庫を持っていると言う：AcctPK、EffectiveDate、Balance、今あなたが潜在的にあなたがこれを追加した場合に更新をカスケード接続するために多数の行を持っていますあなたのDBにはさらに別のカスケードFK関係があります。データウェアハウスが別のデータベースにある場合、参照整合性を強制できないため、カスケードは発生せず、AcctPKが変更される前からアカウントの連続性が失われました。

各行に何らかの情報のサービスを提供するベンダーにデータをエクスポートするとします。現在、ベンダーが結果を返すと、送信したPKがデータに存在しなくなったため、一部の行を照合することはできません。

これらの両方のケースでは、PKの変更履歴を経時的に保持することでこの問題を回避できますが、最終的には（おそらく）PKの選択肢が悪いことを回避することになります。

プライマリキーが頻繁に変更される場合は、その選択を再考することを強くお勧めします。 1つの代替案は代理人IDENTITYまたはautonumberをPKとして使用することです（その代わりにそれに基づいてFK関係で）。カスケード更新は必要ありません。現在、「ナチュラル」主キーとして使用している他のフィールドは、通常のUPDATEでカスケードすることなく変更できます。