PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#26 21/04/2017 08:43:34

jmarsac
Membre

Re : Import CSV: droits, clé primaire, choix champs - sql ou psql et batch?

meonais a écrit :

Je suis dans une structure organisée en agences sur différentes régions.
L'idée est de proposer un outil qui puisse tourner sur n'importe quel poste, qu'il soit connecté au réseau de la structure ou non, pour réaliser un certain nombre de calculs et d'analyses géographiques. Sachant que de toutes façons il n'y a pas de serveur de base de données géographiques unique, chacun se crée son propre serveur sur son propre ordinateur au besoin... (j'espère utiliser les bons termes et me faire comprendre... hmm)

Effectivement, le fonctionnement client/serveur au sens strict (avec dees données centralisées) est exclu

Les utilisateurs de l'outil ne sont pas forcément adeptes de logiciels cartographiques, ou de gestionnaires de base de données, et encore moins de SQL...

C'est pourquoi je cherche à créer cet outil le plus simple possible pour les utilisateurs à venir, sans trop de manipulations et de termes ou noms de logiciels abracadabrantesques wink
Ils sont tous en Windows mais avec une grande disparité de version (de XP -oui oui- à 10?)

L'installation de Postgresql/PostGis + la disponibilité de psql.exe + la disponibilité de shp2pgsql.exe + le script batch + le(s) fichier(s) .sql + les fichiers csv ou shp      me semble une bonne alternative.

Je crois que vous n'échapperez pas à une acquisition minimale de compétences pour les utilisateurs donc de formation (SQL et QGIS).

Ainsi, je souhaitais transmettre l'outil au travers d'un dossier de fichiers [BILAN] avec une arborescence fixe contenant :
- les .exe nécessaires (Postgresql, psql, shp2pgsql, PgAdminIII pour les plus avertis - avec les bonnes versions car elles sont appelées dans le batch)
- les scripts batch et sql
- les fichiers de données permanents au format csv et/ou shp que les scripts importeront dans la base de données
- les fichiers de "données d'entrées" au format csv et/ou shp que l'utilisateur aura à remplacer et que les scripts importeront dans la base de données
- les fichiers résultats produits par les scripts


Et demander à l'utilisateur :
- d'installer Postgresql/PostGis sur leur poste (et PgAdminIII pour les plus avertis)
- de créer la base avec les paramètres indiqués dans mon script batch (ou alors je peux le faire par le script peut-être plus simple ?)
- d'enregistrer le dossier de fichiers [BILAN] au bon endroit (C:\Users\Public\Documents\) afin que les scripts puissent bien tourner
- de lancer le fichier batch


Les "données d'entrée" pour l'analyse sont :
- soit fournies par l'outil : je les ai inclus dans les dossiers de l'outil pour qu'ils soient importés (fichiers shp ou csv) à chaque lancement des analyses. J'avais aussi pensé à un dump, et je ne jette pas l'idée car je pense que j'ai finalement tout intérêt (en complément du script de création de la base ? ... je n'ai encore pas fait ce genre de code hmm)
- soit récupérées auprès d'autres contributeurs : l'utilisateur doit les enregistrer au bon format au bon endroit et l'outil vient les récupérer pour les importer dans la base postgresql.


J'espère avoir été "limpide" dans ces explications ?...
Qu'en pensez-vous ? Est-il possible de simplifier encore ?

PgAdmin sera peut-être plus accessible que psql pour des utilisateurs habitués à Windows
Cela supposerait de préparer une installation personnalisée d'un kit de votre environnement: PostgreSQL+QGIS+données.
C'est possible via des outils Inno Setup, NSIS ou Wix qui permettent de gérer ce qui est installé (ou pas), l'organisation des répertoires, et les versions de Windows. Mais c'est loin d'être anodin et suppose là aussi un minimum de compétences

D'avance merci smile


PS : j'ai encore un gros problème de compréhension et donc de gestion des jeux de caractères, entre le serveur, le client, les fichiers bat et sql... Je suppose qu'il vaudrait mieux poser la question dans un autre post ? Encore merci !

En effet. Une recherche sur les termes "locale", "encodage", "encoding"dans la doc de PostgreSQL devrait déjà vous donner quelques réponses.

Hors ligne

Pied de page des forums