Discussion :

[mballasse]

Bonjour
Je possède une base de données FireBird 2.5 ( ~90 Go - 766 tables - 1329 procédures - 573 triggers - 80 vues) sur Windows Server.

Suite à une demande de modification du service comptable je dois modifié la valeur d'un champ (COD_SITE) d'une table SITE et passer de NT à NA
Or ce champ est utilisé a de multiples endroits dans la base de données comme clé étrangères d'autres tables

Voici donc mon plan de bataille :

• Désactiver tous les triggers
• Déasctiver toutes les FOREIGN_KEY
• Désasctiver toutes les PRIMARY KEY
• Effectuer le changement dnas toutes les tables répertoriées
• Réactiver toutes les PRIMARY KEY
• Réactiver toutes les FOREIGN KEY

Sur le papier aucun souci cela devrait fonctionner sauf qu'en pratique cela ne fonctionne pas
Aucun moyen de désactiver les FOREIG_KEY et les PRIMARY_KEY

D'ou mon message : si quelqu'un a une idée ou une piste

j'ai bien trouvé la solution de supprimer toute sles PRIMARY_KEY et FOREIG_KEY mais solution non envisageable car trop compliqué et risque d'en oublier.

Par avance meric pour votre aide

[licardentaistor]

Si vos contraintes de clé étrangère ont été définies pour effectuer des mises à jour en cascade (ON UPDATE CASCADE), alors modifier la clé primaire dans la table parente devrait automatiquement mettre à jour toutes les clés étrangères dans les tables enfants.

[SergioMaster]

Sur le papier aucun souci cela devrait fonctionner sauf qu'en pratique cela ne fonctionne pas
Aucun moyen de désactiver les FOREIGN_KEY et les PRIMARY_KEY

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER INDEX <indexname> {ACTIVE | INACTIVE}

Maintenant tous les index ce n'est pas forcément nécessaire, seul ceux en rapport avec l'ID de la table SITE seraient nécessaires, une interrogation sur la table système RDB$INDICE permettrait de cibler les index concernés.

pour info, pour obtenir les tables avec cette contrainte de FK

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
SELECT
    detail_index_segments.rdb$field_name field_name,
    detail_relation_constraints.rdb$INDEX_NAME index_name,
    master_relation_constraints.rdb$relation_name reference_table,
    master_index_segments.rdb$field_name fk_field
 
FROM
    rdb$relation_constraints detail_relation_constraints
    JOIN rdb$index_segments detail_index_segments ON detail_relation_constraints.rdb$index_name = detail_index_segments.rdb$index_name 
    JOIN rdb$ref_constraints ON detail_relation_constraints.rdb$constraint_name = rdb$ref_constraints.rdb$constraint_name -- Master indx
    JOIN rdb$relation_constraints master_relation_constraints ON rdb$ref_constraints.rdb$const_name_uq = master_relation_constraints.rdb$constraint_name
    JOIN rdb$index_segments master_index_segments ON master_relation_constraints.rdb$index_name = master_index_segments.rdb$index_name 
 
WHERE
    detail_relation_constraints.rdb$constraint_type = 'FOREIGN KEY'
AND master_index_segments.rdb$field_name='COD_SITE' 
AND master_relation_constraints.rdb$relation_name='SITE'

bon, je n'en suis pas très fier, je n'ai pas utilisé d'alias de table très lisible

Cela étant, il faut aussi (surtout et peut-être seulement ?) désactiver les triggers (table système RDB$TRIGGERS )

[SergioMaster]

À la réflexion, la nuit portant conseil, je tâcherai de créer un script (via l'étude des tables systèmes ?)

1. Supprimer les contraintes de clés devrait suffire ALTER TABLE xxxx DROP CONSTRAINT xxxx
2. un COMMIT pour être sûr.
3. Ensuite modifier la valeur dans la table SITE (UPDATE SITE SET COD_SITE='NA' WHERE CODE_SITE='NT';)
4. Enfin recréer les mêmes contraintes. (FlameRobin peut aider pour récupérer les DDL correspondant) , j'en profiterai pour renommer les contraintes en noms explicites (i.e FK_<nom table>_SITE) et ajouter les ON UPDATE CASCADE si possible

Bien sûr, tout ceci dans une base de données sauvegardée (GBAK) au préalable

[qi130]

Si vos contraintes ...

Avec des "si"

C'est pas souvent que ce cas de figure est imaginé à la conception

[qi130]

Enfin recréer les mêmes contraintes. (FlameRobin peut aider )

Oui, il peut aider, attention cependant :

• il ne les identifie pas toutes (mais je ne me souviens plus sur lesquelles^[edit] il chute, qui sont p-ê sans rapport avec les FK)
• il ne les restitue pas nécessairement dans le bon ordre

[edit] p'têt bien sur les générateurs (sans garantie)

[escartefigue]

bonjour

Suite à une demande de modification du service comptable je dois modifié la valeur d'un champ (COD_SITE) d'une table SITE et passer de NT à NA
Or ce champ est utilisé a de multiples endroits dans la base de données comme clé étrangères d'autres tables

Ce n'est pas pour rien que l'une des règles de d'or, lors du choix de l'identifiant d'un type d'entité (MCD) qui devient clef primaire dans la table correspondante (MLD et MPD) et se propage sous forme de clefs étrangères dans d'autres tables, c'est de prendre une colonne dont le contenu est stable.

Une colonne de contenu stable n'est pas soumises à ce genre de contingences.
C'est la raison pour laquelle il est fortement recommandé d'utiliser un colonne technique dont la valeur est attribuée par le SGBD.
Ça n'empêche nullement de définir une contrainte UNIQUE sur la colonne COD_SITE, mais cette colonne ne devait pas être PRIMARY KEY, car son contenu est sémantique, donc instable !

De plus les identifiants de type integer (cas des colonnes attribuées par le SGBD) sont plus concis, plus performants et insensibles à la collation, contrairement à un type char ou varchar, 3 bonnes raisons supplémentaires pour opter pour ce type d'identifiant

Enfin, dans les tables d'un SGBD relationnel, il n'y a pas de "champs", il y a des "colonnes".