Juste un petit complément

J'ai testé différentes interfaces graphiques avec PostrgreSQL (version 9.1 sous Linux)

A ma connaissance, la seule dans laquelle on peut désactiver l'autocommit (sans avoir à démarrer explicitement une transaction avec BEGIN comme expliqué par gleu ci-dessus) est RazorSQL.

Sinon j'ai aussi testé Tora, là aussi c'est officiellement implémenté, mais çà ne marche pas.

RazorSQL et Tora sont des outils multi-bases (donc qui supportent d'autres bases que PostgreSQL, telles que Oracle, MySQL, etc.). Tora est sous Linux, RazorSQL sous Linux, MacOS ou Windows.

Tora est opensource, RazorSQL propriétaire et payant (69$). RazorSQL me semble vraiment être au-dessus du lot, je trouve que ça vaut les 69$. L'éditeur SQL est notamment bien plus fourni que celui de PGAdminIII ou de Tora, avec des petites astuces bien sympathiques (autocomplétion avec le nom des tables, ce qui évite bien des fautes de frappes, etc...)

non non non, "plperl.so" est bien installé... Je le vois bien dans "/opt/PostgreSQL/9.1/lib/postgresql".

et il y a vraiment très peu d'options lors de l'installation graphique de PostgreSQL, et j'ai tout laissé par défaut. D'ailleurs ça ne parle jamais de perl dans l'installation.

reprenez ce que j'ai écrit dans mon tout premier post :

On voit bien au premier message qu'il n'arrive pas à charger "plperl.so" car il lui manque "libperl.so".
Et quand par la suite je crée un lien symbolique "libperl.so" sur le fichier "libperl.so.5.10.1", le message change, cette fois il ne se plaint plus de ne pas trouver "libperl.so", mais il n'arrive pas à charger "plperl.so" (qu'il trouve bien cependant)

A noter que par curiosité j'ai fait un "sudo find / -name libperl.so" sur ma machine Ubuntu 10.04 avec PostgreSQL 8.4 (donc l'installation pour laquelle je n'ai pas eu de problème pour créer le langage plperl) : il ne me trouve aucun fichier "libperl.so", il a juste "plperl.so" et le "libperl.so.5.10.1" installé par Ubuntu.

Ma déduction logique serait de dire que le plperl de PostgreSQL 9.1 est incompatible avec le Ubuntu 10.04... c'est surprenant quand même

Le fichier libperl qui est installé est le libperl.so.5.10.1

J'en déduis donc que c'est la version 5.10.1 de Perl qui est installée, non ?

J'ai installé Ubuntu 10.04LTS, j'ai téléchargé toutes ses mises à jour, puis j'ai installé PostgreSQL 9.1 (via l'installateur d'Enterprise DB). C'est tout.

Concernant les groupes, on peut en créer des personnalisés en tapant simplement le nom du groupe qu'on veut dans les propriétés des serveurs (clic-droit sur un serveur --> propriétés --> tout en bas on a la liste des groupes, on peut choisir d'affecter le nouveau serveur soit à un groupe existant grâce à la liste déroulante, soit créer un nouveau groupe en tapant simplement le nom).

Par contre apparemment pas moyen de se débarasser du groupe par défaut (celui qui s'appelle "Serveurs"), le serveur qui tourne sous le port par défaut (5432) se retrouve automatiquement dans ce groupe. Si on l'affecte à un autre groupe, il apparaît bien dans l'autre groupe, mais il reste quand même dans le groupe "Serveurs", qu'on ne peut apparemment pas supprimer

ok merci, oui, c'est plus ou moins ce que je comptais faire : en fait je comptais mettre dans la clé primaire le USER (les USERS qui utiliseront un ordi portable avec une base décentralisée devront donc penser à faire la synchro avant de retourner bosser sur le serveur central).

et comme outil pour faire ça, d'après ce que j'ai compris, BUCARDO est le mieux adapté

ok merci c'est clair

la difficulté c'est de choisir le bon outil, il y en a tellement...

Si je résume un peu la grille de choix d'un outil de réplication pour PG (du moins ce que j'en ai compris) :

- si on veut une réplication maître-maître, le choix est Bucardo ou Rubyrep

- si on veut une réplication maître-esclaves avec des esclaves dont l'instance complète est en lecture seule, le choix est la réplication interne de PG

- si on veut une réplication maître-esclaves mais avec uniquement un groupe de table en lecture seule, les autres tables pouvant être en écriture (et pouvant même servir de tables maîtresses pour d'autres réplications), on choisira plutôt Slony (ou Londiste aussi à ce que j'ai lu)

Et par contre même dans ce dernier cas, vous semblez privilégier Bucardo

Finalement, y-a-t-il un cas où vous pensez que Slony serait plus adapté que Bucardo ?

ok merci pour ces infos, à+

Justement, c'est dans ce sens que je pensais qu'il serait peut-être plus simple de le faire manuellement... Comment un outil "généraliste" tel que bucardo peut-il régler les conflits ? A priori, la résolution des conflits ne peut se faire qu'au cas par cas, en fonction de la logique applicative, non ?

Par contre j'ai un autre cas de figure pour lequel il pourrait ne pas y avoir de conflits si les tables sont correctement conçues, je voulais avoir votre opinion pour savoir quel serait l'outil le plus approprié dans ce cas précis :
Une ONG qui travaille dans les pays en voie de développement possède une trentaine de sites répartis dans le pays (appelons les P1 à P30) sur lesquels ils saisissent diverses données (données météorologiques, agricoles, etc...). A ce jour ces sites sont raccordés par une liaison satellite à un site central (appelons le P0) où se situe la base de données. Tout cela fonctionne bien, mais les 30 liaisons satellites sont coûteuses. Ils souhaiteraient effectuer une refonte du système d'information, dans le but essentiellement de faire des économies en terme de télécoms. L'une des pistes envisagées est de conserver les liaisons par satellite, mais au lieu d'avoir 30 liaisons permanentes, de n'en conserver plus qu'une seule qui "balayerait" à tour de rôle chacun des sites distants (on aurait donc tour à tour des liaisons P0-P1, puis P0-P2, puis P0-P3, etc., les liaisons étant à chaque fois établies le temps que la synchronisation puisse se faire)

On aurait donc un serveur sur chaque site, qui devrait se synchroniser avec le serveur central P0 à chaque fois que la connexion est établie. L'objectif est non seulement que P0 centralise les données de tous les autres sites (donc de P1 à P30), mais aussi que sur chaque site ils aient les données des autres, mais bien sur uniquement en lecture seule. Mon idée serait de regrouper les données de chaque site dans un schéma à part (on aurait donc autant de schéma que de sites). Appelons ces schémas de S1 à S30. Le serveur P1 ne peut écrire que dans le schéma S1, le serveur P2 dans le schéma S2, etc...

Donc, lorsque par exemple la liaison P1-P0 est établi, le schéma S1 est mis à jour de P1 vers P0, et les schéma S2 à S30 sont mis à jour de P0 vers P1.
Puis s'établit la liaison P2-P0, le schéma S2 est mis à jour de P2 vers P0, et les schémas S1 et S3 à S30 sont mis à jour de P0 vers P2.
Puis s'établit la liaison P3-P0, le schéma S3 est mis à jour de P3 vers P0, et les schémas S1, S2 et S4 à S30 sont mis à jour de P0 vers P3.
Et ainsi de suites...

On se retrouve toujours encore dans une configuration maîtres-maîtres, vu que lors de chaque établissement de connexion des données sont écrites dans les deux sens, par contre il ne peut pas y avoir de conflits d'écriture, dans la mesure où pour chaque schéma il y a un seul serveur autorisé à écrire dedans.

Pensez-vous qu'une telle architecture est envisageable ? Et si oui, quel est l'outil le plus adapté pour cela ?

ok si je crée le type t_designation ça marche en effet, je pensais qu'on pouvait créer temporairement un type au sein d'une fonction si on n'en a pas besoin ailleurs

une question concernant la façon dont PG gère les vues : j'ai bien compris que pour ramener l'ensemble des articles valides et leur désignation dans la bonne langue, une vue est bien plus performante qu'une fonction qui boucle sur tous les articles

Mais supposons que je veuille ramener la designation d'un seul article.

J'ai deux possibilités :
- soit faire un SELECT sur la vue que je viens de créer (par exemple SELECT designation FROM v_mes_articles WHERE id_article = 212)

- soit utiliser la fonction get_designation (IN article_in INTEGER), cette fonction faisant directement un SELECT dans la table des designations (par exemple SELECT designation FROM designations WHERE id_article = 212 AND langue = get_langue(USER))

Quelle est la meilleure solution ? Pour ramener une seule ligne j'opterais pour la 2ème (la fonction) car je suppose que si on utilise la vue, postgresql doit d'abord la construire avant de ramener la ligne souhaitée (donc construire la vue de toutes les désignations de tous les articles valides dans la langue du user), non ?.

A moins que postgresql n'arrive à optimiser la construction de sa vue en fonction du SELECT (c'est à dire à ne construire qu'une vue partielle, avec uniquement la ligne qui nous intéresse). Il  sait faire ça ?