Discussion :

[jujuco63]

Bonjour à tous,

Je débute en base de données, je travail sous postgreSQL, je voudrais mettre à jour un champ présent dans 3 de mes tables.
Ex: CCOCOM, qui prend la valeur 043 pour chacune de mes lignes quelque soit la table.

J'aimerais via un update mettre à jour le champ dans les 3 tables en une seule requête plutôt que de refaire la requête 3 fois.

Je vous remercie d'avance.

Bonne journée

[aieeeuuuuu]

Bonjour,

Vous ne pouvez pas directement mettre à jour trois tables en une seule requête.
Il faudra donc bien en faire trois.

Cependant, tel que vous décrivez la situation, on peut supposer des erreurs de modélisation :
- cette colonne devrait se trouver dans une seule table et non trois (manque probablement la mise en place d'un héritage)
- en fait cette colonne ne devrait même probablement pas exister, ou pas sous cette forme. Quel est l'interet d'une colonne contenant toujours la même donnée.

ça reste des suppositions, nous n'en savons pas assez pour être plus affirmatif.

[jujuco63]

Je m'explique, je travail avec les données Majic d'une commune. Plusieurs champs apparaissent dans différentes tables.
C'est le cas du champ CCOCOM, qui représente le code INSEE de la commune, 01043. Ce champ me permet d'obtenir par concaténation de plusieurs champs, des nouveaux champs.

ex : Dans ma table des locaux, avec CCOCOM, je peux calculer un nouveau champ (idparcelle) via la concaténation suivante : CCODEP + CCOCOM + CCOPRE + CCOSEC + DNUPLA

Cela me permet de faire la relation entre la table des locaux(bâtiments) et la table des parcelles via le champ idparcelle aussi présent dans la table des parcelles également.
Je ne sais pas si je suis très claire dans mes explications.

Les données sont construites de cette manière par la DGFIP.( je n'ai en aucun cas crée ces champs, ils m'aident simplement à en crées d'autres)

Merci beaucoup

[SQLpro]

Le but d'une base de données est de ne jamais redonder les informations. En ajoutant une colonne d'une table qui concatène le contenu d'autres colonnes d'autres tables, vous ne faites que redonder des informations déjà présente ailleurs.
Vous devez passer par des vues pour ce faire.

A +

[StringBuilder]

Pire que ça : j'ai l'impression que vous avez confondu "clé technique" (généralement un ID auto-incrément dénué de sens, totalement immuable dans le temps) avec "clé logique" (généralement un varchar plein de sens, permettant de façon unique de retrouver une ligne : un numéro de facture, un code INSEE, un code ISO, numéro de SECU, etc.)

Une clé logique NE DOIT JAMAIS servir de clé primaire.

Il y a une erreur flagrande dans votre modélisation.

Vous devriez avoir cette structure :

clé primaire
contrainte d'unicité
clé étrangère

departement (id, CCODEP, nom)
commune (id, departement_id, CCOCOM, nom, population)
PREchaispasquoi (id, commune_id, CCOPRE, etc.)
secteur (id, precheispasquoi_id, CCOSEC, etc.)
dnuplamachine (id, secteur_id, DNUPLA, etc.)
parcelle (id, dnuplamachin_id, NUMPARCELLE, etc.)

Alors que vous avez visiblement :

departement (CCODEP, nom)
commune (CCODEP, CCOCOM, nom, population)
PREchaispasquoi (CCODEP, CCOCOM, CCOPRE, etc.)
secteur (CCODEP, CCOCOM, CCOPRE, CCOSEC, etc.)
dnuplamachine (CCODEP, CCOCOM, CCOPRE, DNUPLA, etc.)
parcelle (CCODEP, CCOCOM, CCOPRE, DNUPLA, NUMPARCELLE, etc.)

Alors qu'avec la première solution, un changement de CCOCOM (code commune) n'affecte qu'une seule ligne dans une seule table, avec la seconde solution cela impacte 5 tables, et notamment leurs clés primaires (qui sont sensées être immuables je vous rappelle) mettant en périle l'intégrité des données pendant la mise à jour (sauf si vous activez la clause CASCADE UPDATE, à compter que vos clés étrangères sont correctement mises en place (ce dont je doute) et que le volume n'est pas trop important sous peine de péter la transaction (si comme avec Oracle on a des erreurs "ROLLBACK SEGMENT FAULT" dès qu'on veut en faire trop d'un coup - avec SQL Server, c'est le journal des transactions qui remplirait le disque à ce moment, ce qui n'est pas spécialement plus heureux)

Accessoirement, les jointures entre tables, avec votre solution, obligent à manipuler énormément de données (à vrai dire, presque les lignes entières) consommant par conséquent énormément de temps et de CPU alors qu'avec la première on reste sur des INT (32 bits généralement c'est amplement suffisant) ce qui permet de gagner certainement quelques centaines de Mo (ou de Go, selon la taille de votre base) en mémoire et de précieuses secondes (ou minutes) à chaque requête.

Et NE CROYEZ SURTOUT PAS que faire une requête :

Code sql :

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

1
2
 
select nom from parcelle where CCODEP = '01'

Soit plus rapide que :

Code sql :

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

1
2
3
4
5
6
7
8
9
 
select p.nom
from departement d
inner join commune c on c.departement_id = d.id
inner join PREchaispasquoi pr on pr.commune_id = c.id
inner join secteur s on s.PREchaispasquoi_id = pr.id 
inner join dnuplamachine d on d.secteur_id = s.id
inner join parcelle p on p.dnuplamachine_id = d.id
where d.CCODEP = '01'

Bien au contraire !