Bonjour,

Je souhaite synchroniser 2 bases de données ayant le même schéma :
- une base "maître" : sur laquelle  nous saisissons des données "communes"
- une base "client" : sur laquelle le client saisi ses propres données

Ces bases de données contiennent donc 2 types de tables :
- les tables "fermées" : que nous sommes les seuls à pouvoir alimenter
- les tables "ouvertes" : sur lesquelles le client peut ajouter ses propres enregistrements

La synchronisation consiste donc à mettre à jour la base "client" avec les données de la base "maître". Nous utilisons pour cela :
- une table "synchronisation" coté serveur, qui contient les champs suivants : id / id_serveur / nom_table / etat / date_maj_serveur => cette table est mise à jour via des triggers positionnés sur les tables impactées par la synchro
- une table "synchronisation" coté client, qui contient les champs suivants : id / id_serveur / id_client / nom_table / date_synchro / modif_client / etat / date_maj_serveur => cette table est mise à jour via le processus de synchronisation
- une table "synchro_entites" coté serveur, qui contient la liste des tables à synchroniser, avec l'ordre associé : id / nom_table / ordre
- une table "synchro_discriminants" coté serveur, qui contient les champs correspondant aux discriminants pour chaque table à synchroniser : id / table_id / ordre / nom_champ / type / parametre (si le champ représente un id d'une autre table)

Les discriminants sont utilisés pour vérifier si une donnée coté serveur corresponds à une donnée coté client lors de la synchronisation.

=> que pensez vous de cette architecture?

J'ai cependant du mal avec certaines des tables que nous synchronisons, et qui sont ouvertes aux clients :
- contacts : id / nom / prenom / id_typecontact / datenaissance / id_paysnaissance / id_nationalite / ...
- club : id / nom / adresse / telephone / id_pays / ville / nomcourt / ...
- competition : id / nom / id_zone / id_categorieage / nomcourt / nom5lettres / ...
en effet, dans ces cas la, les discriminants reposent sur des champs texte (nom/prénom) ou sur des infos qui ne seront pas forcément saisies par le client (datenaissance/id_nationalite)

=> comment réduire au maximum les risques de doublons? faut il imposer aux client la saisie d'informations (datenaissance/id_nationlite) dont ils ne disposeront pas forcément?
=> la solution est elle de prévoir également une interface de gestion des doublons?

Merci,

Bonjour,

Dans ma base de données, j'ai une table CONTACT qui contient des informations nominatives et personnelles (nom, prénom, sexe, date de naissance, etc...).
Je me suis rendu qu'il y avait déja plusieurs "doublons" dans cette base.

Afin de pouvoir les identifier rapidement, j'ai donc exécuté cette requête qui marche parfaitement bien :

SELECT T1.id
FROM contacts T1, contacts T2
WHERE LOWER(T1.nom) = LOWER(T2.nom)
AND LOWER(T1.prenom) = LOWER(T2.prenom)
AND T1.id <> T2.id

Comme il y d'autres cas, avec des accents ou des guillemets, j'ai créé une fonction intermédiaire censée gérer ces cas :

-- Function: fct_format_string(text)
-- DROP FUNCTION fct_format_string(text);

CREATE OR REPLACE FUNCTION fct_format_string(stringtoformat text)
  RETURNS text AS
$BODY$DECLARE formatedString text;
BEGIN
	SELECT LOWER(stringToFormat) INTO formatedString ;
                --SELECT replace(formatedString,'&','') INTO formatedString ;
                --SELECT replace(formatedString,'$','') INTO formatedString ;
	--SELECT replace(formatedString,'*','') INTO formatedString ;
	--SELECT replace(formatedString,'@','') INTO formatedString ;
                --SELECT replace(formatedString,'^','') INTO formatedString ;
	--SELECT replace(formatedString,'#','') INTO formatedString ;
	SELECT replace(formatedString,'æ','ae') INTO formatedString ;
	SELECT replace(formatedString,'â','a') INTO formatedString ;
	SELECT replace(formatedString,'ä','a') INTO formatedString ;
	SELECT replace(formatedString,'à','a') INTO formatedString ;
	SELECT replace(formatedString,'é','e') INTO formatedString ;
	SELECT replace(formatedString,'è','e') INTO formatedString ;
	SELECT replace(formatedString,'ê','e') INTO formatedString ;
	SELECT replace(formatedString,'ë','e') INTO formatedString ;
	SELECT replace(formatedString,'î','i') INTO formatedString ;
	SELECT replace(formatedString,'ï','i') INTO formatedString ;
	SELECT replace(formatedString,'œ','oe') INTO formatedString ;
	SELECT replace(formatedString,'ö','o') INTO formatedString ;
	SELECT replace(formatedString,'ô','o') INTO formatedString ;
	SELECT replace(formatedString,'û','u') INTO formatedString ;
	SELECT replace(formatedString,'ü','u') INTO formatedString ;
	SELECT replace(formatedString,'-','') INTO formatedString ;
	SELECT replace(formatedString,' ','') INTO formatedString ;
	--SELECT replace(formatedString,'_','') INTO formatedString ;
	--SELECT replace(formatedString,'''','') INTO formatedString ;
	--SELECT replace(formatedString,''"','') INTO formatedString ;

RETURN formatedString;
END;$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;
ALTER FUNCTION fct_format_string(text) OWNER TO postgres;

Malheureusement, quand j'exécute la requête précédente avec cette fonction, Postgre mouline énormément et ne m'a toujours pas retourné de résultat après près d'une heure d'exécution...

WHERE C.id in (
SELECT T1.id
FROM contacts T1, contacts T2
WHERE fct_format_string(T1.nom) = fct_format_string(T2.nom)
AND fct_format_string(T1.prenom) = fct_format_string(T2.prenom)
AND T1.id <> T2.id

Y a t'il une autre méthode de faire ce test?
Ai je oublié quelque chose?

Merci,

Bonjour,

J'ai besoin de copier des données issues de plusieurs tables d'une BDD vers une autre.

Je souhaite utiliser la commande COPY car je dois copier seulement une partie de données correspondant à un critère, comme suggéré sur ce topic : http://forums.postgresql.fr/viewtopic.php?id=293

Je n'arrive pas à exécuter ma commande :

COPY 
(select * 
FROM exercices 
WHERE module_id = 2)
TO E'C:\\PCD\\Export\\test.csv';

car j'obtiens le message suivant :

ERREUR: n'a pas pu ouvrir le fichier « C:\PCD\Export\test.csv » en écriture : No such file or directory
État SQL :58P01

Auriez vous une idée?

Je fais cohabiter 2 versions de Postgre sur mon serveur: une 8.4 et une 9.0
Actuellement, c'est encore la 8.4 qui contient la base "source".

Je crée une copie de données à partir de cette table source, via un batch qui exécute la commande suivante :
C:\PostgreSql\8.4\bin\pg_dump.exe --host %nom_serveur% --port 5432 --username postgres -t table1 -t table2 -t table3 --data-only --file "%rep_save%synchro.backup" ma_baseSource

Je restaure le ficher obtenu, à partir d'un autre batch qui exécute la commande suivante :
C:\PostgreSql\9.0\bin\psql.exe -U postgres -f %rep_save%synchro.backup ma_baseDest

Mais j'obtiens le message suivant :
psql: FATAL: la base de données " ma_baseDest " n'existe pas

Je ne comprends pas pourquoi, je suis sur du nom de ma base...

Bonjour,

J'aurais besoin de vos avis et conseils concernant les éventuelles optimisations à apporter aux BDD que nous utilisons sur notre serveur.

- BDD "Prestataire" :
Nous avons une première base de données, qui représente une "copie" des données récupérées chez un prestataire.
Elle est stockée sur notre serveur.
Cette base est mise à jour quotidiennement, et contient plus de 1.5 Go, qui sont réparties dans une dizaine de tables.

- BDD "Mère" :
C'est notre base de données "principale".
Elle contient des données que nous avons saisies et des données que nous récupérons via un processus de synchronisation depuis la base "prestataire".
Elle est stockée sur notre serveur.
Comme nous y stockons des blobs (principalement pour stocker des images), elle est plus conséquente que la base "prestataire" et devrait contenir 2 Go, pour environ 150 tables.

- BDD "Client" :
C'est la base de données du client. Il y en a donc autant qu'il y a de clients.
Elle est stockée sur le poste d'un client, sur le serveur d'un client, ou sur notre serveur.
Cette base est actuellement mise à jour "manuellement", car le processus de synchronisation BDD "Mère" vers "Client" n'est pas finalisé.
Elle contient les mêmes informations que la base "mère" et les données saisies par les clients : 2.5 Go pour environ 150 tables.

J'aurais donc plusieurs questions concernant cette configuration :

- Y a t'il des optimisations particulières à apporter à une base mise à jour une à fois par jour via des webservices?

- Le premier "remplissage" de la base "prestataire" prends environ 2 jours. La synchronisation entre la base "prestaire" et la base "mère" se charge de mettre de données à notre format. Après 10 jours d'exécution, cette étape n'est toujours pas terminée. Il y a certainement des optimisations à apporter dans le code, mais y aurait il également des optimisations à apporter au niveau du serveur Postgre?

- Nous hébergons les bases de certains clients qui n'ont pas de serveur et qui ont besoin de pouvoir partager les données. Du coup, nous avons actuellement une dizaine de bases sur notre serveur. Cela peut il impacter sur les performances de Postgre? (sachant que toutes les bases ne sont pas "utilisées" en même temps)

Je précise que je n'y connais pas grand chose en maintenance de base de données, et que si le travail à faire est important nous pourrions envisager une collaboration de quelques jours pour formation + optimisation...

Merci d'avances pour vos remarques et suggestions.