comment mettre à jour la même colonne dans plus d'un tableau

Question

Je veux la déclaration de la façon de mettre à jour la même colonne dans plus d'une table dans la même base de données sql mais ces tables sont liées entre elles par cette colonne en une et forgin clé dans les autres tables avec C# s'il vous plaît aidez-moi

Answer 1

Changer une clé primaire n'est jamais amusant: c'est pourquoi beaucoup de gens préfèrent synthetic aux touches naturelles. Il n'existe pas de méthode SQL standard à une seule instruction; à la place, vous devez insérer une copie de la ligne de la table principale avec la nouvelle clé primaire, UPDATE la table enfant (s) pour faire référence à la nouvelle ligne et supprimer la ligne d'origine.

Answer 2

Ce que vous voulez peut être spécifié sur la contrainte de clé étrangère. Cochez ici, par exemple le MySQL syntax.

Quelque chose comme cela devrait fonctionner pour votre dialecte sql aussi.

[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 | 
+------+------+ +------+------+ 

Dans cet exemple il pourrait y avoir un problème en fonction de votre DB-System. Si le système DB ne vérifie pas si un PID est déjà assigné en "mode AUTOINC", la valeur auto-incrément peut atteindre 5000 et l'insertion peut échouer car il y a déjà une ligne avec ce PID. Dépend de la manière dont votre système DB passe la modification de la colonne de clé primaire quand un incrément automatique est spécifié

Answer 3

Ce que vous voulez répondre à votre question est une clé étrangère avec une mise à jour en cascade, comme mentionné dans la réponse de jitter. Cependant, comme la plupart des considérations de conception, vous n'auriez pas à poser cette question si vous êtes retourné et analysé votre besoin sous-jacent pour effectuer ce type d'opération. Bien que cela fonctionne, cela signifie que la clé primaire sur vos entités de base de données n'est pas fiable au fil du temps, et cela signifie également que la base de données peut faire énormément de travail en cascade (et elle devra maintenir plus de verrous dans l'exécution d'une telle mise à jour, ce qui augmente la probabilité de blocage).

En ce qui concerne la fiabilité au fil du temps, que vous avez un entrepôt qui maintient les soldes historiques sur un compte: AcctPK, EffectiveDate, Balance, maintenant vous avez potentiellement un grand nombre de lignes en cascade la mise à jour si vous ajoutez cela comme encore une autre relation FK en cascade dans votre base de données. Si l'entrepôt de données se trouve dans une base de données distincte, vous ne pouvez pas appliquer l'intégrité référentielle, donc aucune cascade ne se produit, et maintenant vous n'avez plus la continuité du compte avant AcctPK a été modifié. Supposons que vous exportiez les données à un fournisseur qui fournit un service contenant un type d'information pour chaque ligne. Maintenant, lorsque le fournisseur renvoie les résultats, vous ne pouvez pas faire correspondre certaines lignes car le PK que vous avez envoyé n'existe plus dans vos données. Dans ces deux cas, vous pouvez contourner ce problème en conservant les enregistrements de modification des modifications PK dans le temps, mais en fin de compte, il s'agit de contourner un (probablement) mauvais choix de PK.

Je vous suggère fortement de reconsidérer votre choix de clé primaire si elle change fréquemment. Une alternative serait d'utiliser un substitut IDENTITY ou autonumber comme PK (avec la relation FK basée sur cela à la place). Il n'aura jamais besoin d'une mise à jour en cascade, et l'autre champ que vous utilisez actuellement comme une clé primaire "naturelle" peut être changé dans un UPDATE normal sans avoir à faire une cascade.