Discussion :

[SNY77]

Bonjour,
On a deux serveurs SQL avec deux BDD de structure identique (régulièrement on fait des BACK UP et DELETE car on se retrouve avec énormément de ligne ...). On me demande d'avoir une 3ème BDD sur un 3ème serveur SQL qui regroupe les données des deux BDD (il n'y a pas de clés dans la BDD ).
J'ai penser à décomposer la tâche de la manière suivante :
- Réaliser un BACK UP avant toute opération (j'ai un script en BAT pour ça ...) ;
- Importer les deux BDD vers le 3ème serveur (uniquement les nouvelles données et sans écraser les anciennes)
Je programmerai après l'execution du script (si c'est pas possible avec un logiciel, même payant!)
Je ne vois pas comment m'y prendre ?
Merci;

[CinePhil]

On a deux serveurs SQL avec deux BDD de structure identique

(il n'y a pas de clés dans la BDD ).

Il y a décidément des choses à revoir dans votre informatique !

J'ai penser à décomposer la tâche de la manière suivante :
- Réaliser un BACK UP avant toute opération (j'ai un script en BAT pour ça ...) ;
- Importer les deux BDD vers le 3ème serveur (uniquement les nouvelles données et sans écraser les anciennes)

Oui et ensuite fusion dans la nouvelle BDD :
- directement si vous vous contentez de travaillez toujours aussi mal ;
- de manière plus méthodique si vous voulez vous améliorer en faisant d'abord un modèle de données normalisé. On peut vous aider dans le forum Schéma pour ça.

[SNY77]

Au fait, la BDD existe déjà depuis très longtemps je ne touche pas à la structure mais j'étais étonne lorsque j'ai vu qu'ils n'y avaient pas de clés. On voudraient faire une MAJ régulièrement sur la 3ème BDD (uniquement les nouvelles données des BDD 1 et BDD2). Vous conseillez un script ou bien une appli existe déjà ?

[CinePhil]

Et bien cette fusion me semble le moment idéal pour réorganiser tout ça, quitte bien sûr à utiliser des vues pour que les logiciels qui utilisent les BDD ne soient pas perdus et n'aient pas à être modifiés.

Par contre, avec MySQL, ce sera plus compliqué côté insertion et modification de données.
La question mérite quand même d'être étudiée, surtout si vous avez de grosses quantités de données. Actuellement, ça ne doit pas être très performant tout ça !

[SNY77]

Non mais on a une nouvelle BDD avec des clés ... (je suis que stagiaire) donc tu me dis que le script PHP/SQL n'est pas une bonne idée? J'ai entendu parler d'une appli (TALEND) ...

[CinePhil]

Non mais on a une nouvelle BDD avec des clés

C'est la nouvelle BDD que tu dois alimenter par fusion des deux anciennes ?

le script PHP/SQL n'est pas une bonne idée?

De quel script parles-tu ?

S'il s'agit effectivement d'importer dans une BDD normalisée des données venant de BDD mal foutues, oui, il va falloir faire des requêtes SQL méthodiquement pour répartir correctement les données dans les tables de la nouvelle BDD. Ça peut se faire directement par un script SQL mais il sera peut-être parfois nécessaire d'utiliser un programme externe, par exemple en PHP.

J'ai eu à re-concevoir une BDD il y a quelques années et j'ai dû utiliser des petits programmes PHP pour éclater des colonnes multi-valuées afin de répartir ces valeurs à l'endroit où elles devaient être dans la nouvelle BDD mais j'ai fait l'essentiel de la migration en SQL direct.

Il faut être très méthodique et tester chaque étape, les contrôler avec des requêtes pour vérifier que les nouvelles données correspondent bien aux anciennes, identifier les lignes manquantes et la cause de l'échec de leur importation (souvent des données mortes, inexploitables).

[SNY77]

Non je travaille sur les anciennes. Les trois BDD ont la même structure.
Je pensais a taper un script qui entre uniquement les nouvelles données provenant des back up des BDD 1 et BDD 2 (une fois par moi par exemple, le script back up est un bat).

[heretik25]

Avec un ETL du type Talend Open Studio ou en payant (mais gratuit 30jours) FME.

[CinePhil]

Non je travaille sur les anciennes. Les trois BDD ont la même structure.
Je pensais a taper un script qui entre uniquement les nouvelles données provenant des back up des BDD 1 et BDD 2 (une fois par moi par exemple, le script back up est un bat).

Autrement dit, vous ajoutez du bordel au bordel !

Heureusement que tu n'es que stagiaire ! Ne postule pas à un emploi dans cette boîte !

[SNY77]

c'est une très grande boite ... Alors quelle est la solution la plus simple pour vous ?

[CinePhil]

En méthode sale, un banal script SQL rempli de requêtes de ce style :

Code SQL :

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

1
2
3
INSERT INTO table_n
SELECT *
FROM bdd_x.table_n

Pas besoin de PHP.

[SNY77]

Le soucis c'est la gestion des données déjà existante sur la 3ème BDD ? Il est peut être possible de sélectionner les données des BDD1 et 2 non existante sur la 3ème.

[CinePhil]

Ben il suffit d'ajouter les conditions nécessaires pour empêcher l'écrasement des données :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
INSERT INTO bdd3.table_n n
SELECT *
FROM bdd_x.table_n nx
WHERE NOT EXISTS
(
	SELECT 1
	FROM bdd3.table_n n3
	WHERE n3.colA = nx.colA
		AND n3.colB = nx.colB
		-- etc.
)

[SNY77]

Ok merci, donc en gros dans mon script :
1/ Connexion au 3 BDD (je créerai un utilisateur sur chaque serveur SQL ...)
2/ Je rentre ta requête INSERT INTO pour la BDD 1 et ensuite la BDD 2 en vérifiant champs par champs si les données existent déjà ou nn .
C'est bien ça ? Le mieux serait de taper ça sous forme SQL ou en BATCH ?

[CinePhil]

1) Les champs sont à la campagne ou dans les formulaires, pas dans les tables SQL qui ne sont composées que de colonnes et de lignes.

2) Pas besoin de se connecter aux trois BDD.
Tu te connectes au SGBD puis tu fais des requêtes multi-BDD comme je viens de le faire selon le principe suivant :

Code SQL :

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

1
2
3
4
INSERT INTO bdd3.table1 t31
SELECT *
FROM bdd1.table1 t11
-- etc.

3) Pas un contrôle de chaque colonne individuellement mais du groupe de colonnes permettant d'identifier de manière unique chaque ligne de la table. On appelle ça une clé candidate et il peut y en avoir plusieurs dans une table.

Par exemple, soit la table suivante où le mauvais créateur a omis de créer une clé primaire :
personne (nom, prenom, date_naissance, date_creation, adresse, telephone)

Il peut y avoir plusieurs Jean Dupont donc le couple {nom, prenom} n'est pas suffisant comme clé.
Il peut y avoir plusieurs Jean Dupont nés le 15/05/1950 mais c'est beaucoup moins probable. Une requête sur la table permet de vérifier si le triplet {nom, prenom, date_naissance} peut être une clé candidate :

Code SQL :

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

1
2
3
4
SELECT nom, prenom, date_naissance
FROM personne
GROUP BY nom, prenom, date_naissance
HAVING COUNT(*) > 1

Si la requête retourne des lignes, le triplet n'est pas clé candidate.

On peut ensuite faire pareil avec d'autres ensembles de colonnes afin de trouver l'ensemble qui peut constituer la clé et c'est cette clé qu'il faut utiliser dans la condition de restriction pour éviter l'écrasement des données existantes dans la BDD 3.

[SNY77]

Concernant les clés, je pense qu'il serait plus judicieux de s'assurer qu'on a pas de lignes identiques (donc avec tous les champs ...). Ca simplifie du coup le script parce que le je suis un peu perdu

[rawsrc]

Salut,

[HS]
Ils ont l'air de bichonner leur stagiaire dis donc
[/HS]

J'espère qu'ils supervisent au moins...

[CinePhil]

Oui, il suffit de compléter mon WHERE avec toutes les colonnes de la table :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
INSERT INTO bdd3.table_n n
SELECT *
FROM bdd_x.table_n nx
WHERE NOT EXISTS
(
	SELECT 1
	FROM bdd3.table_n n3
	WHERE n3.colA = nx.colA
		AND n3.colB = nx.colB
		-- etc.
)

[SNY77]

Ok, merci je vais tester ça et je vous tiendrai au courant ! Je fais ça dans un fichier SQL c'est mieux ? Et après je l'exécute; Parcontre je devrais quand même me connecter aux 3 SGBD ? Apparemment j'ai des clés primaires dans certaines tables : (je pensais pas car pas colonnes ID ...)

Code :

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

PRIMARY KEY (`num_serie`,`date`) USING BTREE

Je teste donc que les champs que je retrouve dans les clés primaires (dans le cas précédent les deux champs num_serie et date) ?
Merci;

[CinePhil]

Ben voilà ! Avec des clés primaires, c'est quand même déjà mieux !

Tu devras te connecter aux BDD 1 et 2 pour récupérer les données par DUMP mais j'ai cru comprendre que tu avais déjà un script pour exporter ces deux BDD dans le nouveau serveur.

Une fois cet export fait, tu te connectes au serveur 3 puis tu exécute les requêtes une à une en phase de test et en vérifiant que tu ne perds ni n'écrase de données en route (mais avec les clés primaires, normalement, il ne devrait pas y avoir de problème).

Ensuite, quand tout est prêt, tu vide la nouvelle BDD puis tu mets tes requêtes dans un fichier .sql que tu exécutes pour voir si la procédure passe d'un seul coup avec ce ficher.

Code :

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

mysql -u nom_user_mysql -pson_mot_de_passe bdd3 < chemin/vers/fichier.sql