Discussion :

[Brebiou]

Bonjour à tous,

Je dois modifier un code fournisseur pour environ 400 fournisseurs, code qui est dans la colonne ID_FOU présentes dans 27 tables, de façon à mettre à jour l'intégralité du système avec la nouvelle syntaxe de l'ERP pour les fournisseurs.
Pour éviter de taper (ou faire taper à Excel mon copain) l'équivalent de 11000 requêtes SQL, je venais voir si il n'existait pas une sorte de "raccourci".

J'ai pas mal cherché du coté d'un UPDATE avec jointure, mais j'avoue que j'ai eu du mal a trouver un exemple s'approchant de ce que je souhaitais faire.

Je suis familier du langage SQL mais ce n'est pas mon cœur de métier. Donc je ne suis pas un débutant mais pas du tout un expert

Merci de vos réponses

[vanagreg]

Bonjour,

Tu peux te servir du dictionnaire de données de la base pour retrouver les tables. Par exemple sur Oracle, tu peux générer les instructions update ainsi:

Code :

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

1
2
3
select 'update ' || table_name || ' set id_fou = valeur_cible where id_fou = valeur_souce;'
from user_tab_cols
where column_name = 'ID_FOU';

Tu peux aussi faire un petit bloc PL/SQL qui exécuterait ces update.

[tatayo]

Bonjour,
Tu peux créer une table temporaire avec 2 colonnes, une pour l'ancien code et une pour le nouveau.
A partir de là tu n'as besoin que d'une requête par table, avec une jointure:

Code sql :

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

1
2
3
4
5
 
update LaTable
set CodeFrn = traduction.NouveauCode
from LaTable
inner join traduction on traduction.AncienCode = LaTable.CodeFrn

Il faut juste remplir la table en question.

Mais c'est quand je vois cet genre de "problématique" que je sais pourquoi je me suis battu bec et ongles en interne pour que les clés étrangères soient des Identifiants numériques, et non des codes.
Si je devais faire ce genre de manipulation, seule la table fournisseur serait à modifier.
Et encore, dans certains cas j'utilise une table de "traduction", qui est utilisée dans les flux d'échange de données.

Tatayo.

[escartefigue]

Attention : vu que la colonne concernée s'appelle ID_fou il est fort probable qu'il s'agisse d'une clef primaire dans l'une des tables et qu'on la retrouve comme clef étrangère dans d'autres tables.

Si c'est bien le cas, il faut vérifier s'il y a une instruction ON UPDATE CASCADE sur la table où cette colonne est PK, selon le cas, la marche à suivre n'est pas la même.

[sevyc64]

Si c'est bien le cas, il faut vérifier s'il y a une instruction ON UPDATE CASCADE sur la table où cette colonne est PK, selon le cas, la marche à suivre n'est pas la même.

Il y a le monde de Bisounours, et il y a la réalité du terrain

[Brebiou]

Bonjour à tous,

Tout d'abord, merci de vos réponses.

Attention : vu que la colonne concernée s'appelle ID_fou il est fort probable qu'il s'agisse d'une clef primaire dans l'une des tables et qu'on la retrouve comme clef étrangère dans d'autres tables.

Si c'est bien le cas, il faut vérifier s'il y a une instruction ON UPDATE CASCADE sur la table où cette colonne est PK, selon le cas, la marche à suivre n'est pas la même.

Effectivement, la clé est bien primaire dans la table fournisseur, mais je n'ai pas moyen de savoir les autres ont été déclaré comme clé étrangères dans les autres tables.
Comment puis je m'assurer qu'un ON UPDATE CASCADE est possible?
Au passage, j'ai appris ce qu'était la notion de clés étrangères.

Bonjour,
Tu peux créer une table temporaire avec 2 colonnes, une pour l'ancien code et une pour le nouveau.
A partir de là tu n'as besoin que d'une requête par table, avec une jointure:

Code sql :

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

1
2
3
4
5
 
update LaTable
set CodeFrn = traduction.NouveauCode
from LaTable
inner join traduction on traduction.AncienCode = LaTable.CodeFrn

Il faut juste remplir la table en question.

Je vais creuser le principe des tables temporaires.

Mais c'est quand je vois cet genre de "problématique" que je sais pourquoi je me suis battu bec et ongles en interne pour que les clés étrangères soient des Identifiants numériques, et non des codes.
Si je devais faire ce genre de manipulation, seule la table fournisseur serait à modifier.
Et encore, dans certains cas j'utilise une table de "traduction", qui est utilisée dans les flux d'échange de données.

Tatayo.

Techniquement, le "code" de départ est un entier (900235, 901253, etc) et il doit passer sous la forme ERP (F00235, F01253, etc). Heureusement que le type de donnée est varchar .

Bonjour,

Tu peux te servir du dictionnaire de données de la base pour retrouver les tables. Par exemple sur Oracle, tu peux générer les instructions update ainsi:

Code :

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

1
2
3
select 'update ' || table_name || ' set id_fou = valeur_cible where id_fou = valeur_souce;'
from user_tab_cols
where column_name = 'ID_FOU';

Tu peux aussi faire un petit bloc PL/SQL qui exécuterait ces update.

Ouah, tu dépasse de loin mes maigres compétences, mais je vais creuser, ne serais ce que pour ma culture personnelle.
[EDIT] Ah, je crois que c'est le même principe qu'une requête que j'utilise pour retrouver la présence de la colonnes dans toutes les tables de la BDD!

Code sql :

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

1
2
3
4
SELECT c.name AS nomColonne, t.name AS nomTable
FROM sys.columns c
	JOIN sys.tables t ON c.object_id = t.object_id
WHERE c.name LIKE 'ID_FOU'

[escartefigue]

Effectivement, la clé est bien primaire dans la table fournisseur, mais je n'ai pas moyen de savoir les autres ont été déclaré comme clé étrangères dans les autres tables.
Comment puis je m'assurer qu'un ON UPDATE CASCADE est possible?
Au passage, j'ai appris ce qu'était la notion de clés étrangères.

Les clefs étrangères sont fondamentales : ce sont elles qui permettent au SGBD de garantir l'intégrité des données. Par exemple, de vérifier qu'une ligne de facture est bien rattachée à une facture existante !
Pour trouver quelles sont les clefs étrangères, il faut consulter les tables du catalogue relationnel. La structuration du catalogue relationnel dépend du SGBD, quel est le votre ?

Par exemple, pour SQL server, il faut consulter sys.foreign_keys et information_schema.referential_constraints, sur DB2 for Z/OS ce sont les tables sysibm.sysrels et sysibm.sysforeignkeys...

[Brebiou]

Les clefs étrangères sont fondamentales : ce sont elles qui permettent au SGBD de garantir l'intégrité des données. Par exemple, de vérifier qu'une ligne de facture est bien rattachée à une facture existante !
Pour trouver quelles sont les clefs étrangères, il faut consulter les tables du catalogue relationnel. La structuration du catalogue relationnel dépend du SGBD, quel est le votre ?

Par exemple, pour SQL server, il faut consulter sys.foreign_keys et information_schema.referential_constraints, sur DB2 for Z/OS ce sont les tables sysibm.sysrels et sysibm.sysforeignkeys...

C'est effectivement le constat que j'en ai fait en me documentant dessus.

Je suis sous SQL Server, et il était normal que je ne trouve pas mes clés étrangères car il n'en existe aucune!



Ou alors je n'ai pas les droits nécessaires à leur visualisation, ce qui m'étonnerait quand même. Je vais essayer de voir avec le SI qui à un accès admin sur la base.

[escartefigue]

L'absence de FK sur SQL server c'est encore pire, car non seulement l'intégrité des données n'est pas garantie (comme sur tout SGBD), mais en plus l'optimisation sémantique n'est pas possible !

SQL server utilise les contraintes CHECK et FK pour optimiser certaines requêtes, si pas de contrainte, ces optimisations sont impossibles.

[al1_24]

Il y a encore pas si longtemps j'ai du me battre avec des "DBA de production" pour mettre en place des contraintes d'intégrité référentielle dans une base de données.
Leurs arguments étaient que "ça ralentit les insertions" et "ça peut bloquer des mises à jour ou des suppressions" voire "empêcher des restaurations de sauvegardes".

Que je suis heureux d'être à la retraite !

[tatayo]

al1_24: j'ai les mêmes à la maison !
Manque de bol, je suis loin d'être à la retraite
Mais j'ai quand même presque réussit à les convaincre de l'utilité l'importance des contraintes, que les Id auto ne posent pas de problème en maintenance, qu'une vue avec un trigger INSTEAD OF permet de simplifier celle-ci… J'ai encore du chemin, mais je ne lâche pas l'affaire.

Tatayo.

[SQLpro]

Sous SQL Server pour savoir si vous avez des contraintes d'intégrité (pas des clés étrangères) référentielles, il faut lancer la requête suivante :

Code :

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

SELECT * FROM INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS

Dans le contexte de la base cible.

A +

[Brebiou]

Bonjour à tous,

Donc l'informaticien n'en voit pas plus, signe qu'il n'existe aucune clés étrangères.

Sous SQL Server pour savoir si vous avez des contraintes d'intégrité (pas des clés étrangères) référentielles, il faut lancer la requête suivante :

Code :

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

SELECT * FROM INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS

Dans le contexte de la base cible.

A +

Je l'avais faite juste après en cherchant un peu, mais dans le doute, je viens de l'exécuter: 0 lignes retournées!

J'ai donc devant moi un gros problème de moralité:

1. La méthode j'ai rien vu
   Je génère mes requêtes avec mon ami Excel pour effectuer ma modification, un coup de copier coller et je retourne à mes pénates sans rien dire à personne.
   C'est la facilité, sachant qu'aucune personne n'ira mettre le nez dans la BDD à part moi, et que le système à l'air de se satisfaire de son "état", qui suis je pour le juger?
2. La méthode je corrige tout
   Je m'amuse à me documenter encore et encore sur un métier qui n'est pas le mien afin de modifier la base de données pour que ça soit plus sécure.
   C'est mon esprit logique qui parle, soit tu fais correctement, soit tu fais pas (0 ou 1), mais ça va demander du temps et de l'énergie que je n'ai pas forcement à l'instant T

De plus, c'est un logiciel de gestion qui est édité par une entreprise encore en exercice, donc modifier la BDD reviendrait peut-être à violer certaines clauses du contrat de vente/maintenance, je dois déjà vérifier cela.
Le souci c'est que la moindre modif, c'est passage au tiroir caisse, et que clairement, demander cela ne changera rien "visuellement" pour les non initiés, donc argumenter une demande d'invest pour ça à ma direction, c'est peine perdue.
Cela étant, je m'étonne qu'un système tel que celui ci ne soit pas "carré" en terme de programmation, et je commence peut être à comprendre pourquoi les commerciaux plébiscite les versions cloud, pour pas qu'on mette les mains dans le moteur.
Ceci dit, je pensais avoir un bi-turbo alors que j'ai plus l'impression d'avoir un 1.1L.

[escartefigue]

Modifier la définition une base de données alors que ce n'est ni votre mission ni votre spécialité, c'est faire courir un grand risque à vous même et à votre entreprise.

Si vous faites vous mêmes les modifications sans rien dire, vous risquez de faire des erreurs qui vous seront difficiles à rattraper puisque vous n'êtes pas qualifié pour.

Et si vous n'alertez pas votre hiérarchie, vous risquez qu'on vous le reproche.

Dans les deux cas, ça peut se retourner contre vous.

Ce qu'il faut faire, c'est donc alerter par écrit (pour laisser des traces) sur ce que vous constatez et réclamer l'intervention d'une personne dont la maintenance de la BDD est le métier, c'est à dire un DBA.
Il peut s'agir d'une ressource interne ou d'une prestation d'un fournisseur, peu importe, mais en tout cas d'un sachant.
Ensuite, c'est votre hiérarchie qui décidera ce qu'il convient, ou pas, de faire, mais au moins, vous aurez fait votre devoir

[Brebiou]

Modifier la définition une base de données alors que ce n'est ni votre mission ni votre spécialité, c'est faire courir un grand risque à vous même et à votre entreprise.

Si vous faites vous mêmes les modifications sans rien dire, vous risquez de faire des erreurs qui vous seront difficiles à rattraper puisque vous n'êtes pas qualifié pour.

Et si vous n'alertez pas votre hiérarchie, vous risquez qu'on vous le reproche.

Dans les deux cas, ça peut se retourner contre vous.

C'est exactement pour ces raisons que je vérifie mon périmètre d'action "autorisés" diront nous.
Sur la demande de départ, je ne fait que mettre à jour des enregistrements, donc impact assez limités, mais qui doivent être pesé car ça porte sur 5% des tables de la BDD.

Ce qu'il faut faire, c'est donc alerter par écrit (pour laisser des traces) sur ce que vous constatez et réclamer l'intervention d'une personne dont la maintenance de la BDD est le métier, c'est à dire un DBA.
Il peut s'agir d'une ressource interne ou d'une prestation d'un fournisseur, peu importe, mais en tout cas d'un sachant.
Ensuite, c'est votre hiérarchie qui décidera ce qu'il convient, ou pas, de faire, mais au moins, vous aurez fait votre devoir

C'est déjà en cours.
J'ai assez d'expérience dans le monde du travail pour savoir que les paroles s'envolent, mais les écrits restent
Merci à tous en tout cas pour tout ces enseignements sur le SQL, car j'ai bouffé de la doc ces derniers jours.

Je passe la discussion en résolu car ça ne va plus dépendre que de moi même.

[Waldar]

Sur la demande de départ, je ne fait que mettre à jour des enregistrements, donc impact assez limités, mais qui doivent être pesé car ça porte sur 5% des tables de la BDD.

Il n'y a pas de corrélation entre le nombre de lignes mises à jour et les impacts sur une base de données.
Insérer une deuxième ligne dans DUAL sous Oracle Database, modifier un taux de TVA, ce sont des toutes petites opérations mais les conséquences sont vite désastreuses.