#1 Mon 12 September 2011 13:16
- PaulH
- Participant assidu
- Lieu: Nantes
- Date d'inscription: 1 Aug 2007
- Messages: 463
SGBD: quelles solutions pour quelles taille?
Bonjour,
La collectivité dans laquelle je travaille (une "petite" ComCom rurale) souhaite passé à une solution libre. Nos principaux partenaires migrent eux aussi vers QGIS. Je pensais donc aller vers ce logiciel.
Du coup, j'essaye d'avoir une réflexion plus large sur la réorganisation du SIG dans sa globalité et les solutions techniques à mettre en place afin de posséder un outil péren et utilisé par l'ensemble des agents. Cette réflexion me semble d'autant justifié qu'il n'existe encore presque rien, tout est à construire. Le SIG était plutôt utilisé comme DAO avt.
Les compétences qui utilisent ou pourraient utiliser de la cartographie sont les suivantes:
-urbanisme (dans la réalisation des documents de planification:Cartes Communales)
- assainissement (qui utilise un logiciel métier Anc-Map)
- voirie
- signalétique
Les données concernant l'urbanisme sont à jour et ont fait l'objet d'une réorganisation (standard CNIG). L'assainissement possède aussi une structure fiable avec la base de donnée stockée sous Excel. Pour l'instant nous ne possédons pas encore de serveur, ni de SGBDR. Chaucun est en local. Un projet est justement lancé pour l'acquisition d'un serveur.
Après cette présentation, je vais vous faire part de mes interrogations.
Ma première question porte sur le SGBDR à mettre en place. A partir de quand doit-on passer à une association logiciel SIG+SGBDR? notre collectivité ne possédant pas énormément de données, doit-on mettre en place une solution aussi lourde compte tenu de notre taille (3/4 agents pourraient être amené à y toucher)? ou les tables attributaire dans QGIS suffisent? Quel SGBDR est le plus adapté pour QGIS? postgre/postgis? spatialite?
Peut on envisager de gérer l'assainissement et donc la partie dossier directement avec QGIS (dans le but d'une homogénéiation)?ou faire taper anc-map sur le SGBDR? ou encore que l'assainissement reste autonome?
Concernant la voirie et la signalétique, rien est encore en place. Existe-t-il des standards, des règles de BD? dois-je créer une BD voirie et une BD signalétique indépendante avec un MCD propre? ou vu la faible quantité de données une gestion attributaires dans QGIS est suffisant?
voilà, c'est à peut près tout. N'hésitez pas à me demander plus de détail.
Merci bcp pour vos futurs conseils, même pour une question votre aide m'est utile. Un retour d'expérience pour une structure de la même taille et les même compétences seraient parfait !!!
Paul Hedin
ex-luern
Hors ligne
#2 Mon 12 September 2011 14:44
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3199
- Site web
Re: SGBD: quelles solutions pour quelles taille?
Bonjour,
A partir de quand doit-on passer à une association logiciel SIG+SGBDR
A partir de l'instant où les données exploitées possèdent des relations entre elles. Vous répondez d'ailleurs vous même à la question en parlant des tables attributaires QGis. Si la donnée et ses attribut peuvent être contenues dans une table sans relation avec une autre un "simple" logiciel SIG suffit.
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#3 Mon 12 September 2011 21:35
Re: SGBD: quelles solutions pour quelles taille?
Bonsoir,
Un autre argument à étudier pour passer (ou pas) à une solution de type SGBDR concerne la gestion des accès concurrents.
Mais si vous êtes peu nombreux à procéder aux mises à jour des données, il faut vraiment vous poser la question d'une solution "lourde" (compétences en administration de BD).
Si vous avez déjà un existant du coté des applications métiers, il faut également tenir compte du fait que ces outils pourront (ou pas) bénéficier des avantages du futur SGBDR.
Bruno
Hors ligne
#4 Tue 13 September 2011 09:24
- PaulH
- Participant assidu
- Lieu: Nantes
- Date d'inscription: 1 Aug 2007
- Messages: 463
Re: SGBD: quelles solutions pour quelles taille?
c'est pour ça que je me posais des questions sur une telle mise en place, même si ça reste l'idéal dans une perspective de développement de l'information géographique.
Cependant, ne serait-il pas nécessaire d'en installer un lorsque le serveur de ma collectivité sera en place?
De plus, avec la prochaine constitution d'une composante voirie et signalétique, un besoin en SGBD devrait apparaitre (je n'ai pas encore fait l'analyse des besoins)?
L'assainissement pour l'instant avec son fonctionnement autonome ne devrait pas pour l'instant subir de changement.
Paul Hedin
ex-luern
Hors ligne
#5 Tue 13 September 2011 10:24
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3199
- Site web
Re: SGBD: quelles solutions pour quelles taille?
Bonjour,
Il faut faire une distinction entre logiciel et système, au sens ou les logiciels SIG sont en général très forts pour la cartographie, mais au niveau données ils ne savent manipuler nativement que des tables attributaires simples. En revanche les SGBDRS permettent d'intégrer des modèles de données complexes (ce qui nécessite une technicité particulière), et donc de fournir un résultat simple à une requête complexe (agrégat) en vue de son utilisation dans un SIG.
Par exemple pour les données cadastrales, il est facile avec un SGBDRS de créer une table contenant l'ensemble des parcelles des propriétaire âgés de plus de 50 ans ayant un nom qui commence par T et nés en Mars, et il est très facile ensuite d'en faire une très belle cartographie avec un logiciel SIG. L'inverse est beaucoup moins pertinent.
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#6 Tue 13 September 2011 10:45
- PaulH
- Participant assidu
- Lieu: Nantes
- Date d'inscription: 1 Aug 2007
- Messages: 463
Re: SGBD: quelles solutions pour quelles taille?
En reprenant ton exemple, je n'ai pas besoin de posséder une telle information . cela signifie t -il que mon système n'a pas besoin d'un SGBDR?
Avec un serveur de donnée commun à tous les services, il me semble qu'un SGBDR commun où les personnes puissent venir taper au même endroit et utilisant le même logiciel est plus logique??
Paul Hedin
ex-luern
Hors ligne
#7 Tue 13 September 2011 11:07
- Pierre
- DesCartesPourUnMondeMeilleur
- Date d'inscription: 22 Sep 2005
- Messages: 1643
Re: SGBD: quelles solutions pour quelles taille?
Aloha
Une solution SGBDR est aussi et avant tout, à mon humble avis (et là je vais dans ton sens luern), une façon de consolider des données et de les mettre dans le pot commun des données accessibles par les agents d'une ComCom. Ce qui est bien plus compliqué, me semble-t'il lorsque l'on conserve une arborescence type fichier. J'ai un SGBDR et doit avoir en tout et pour tout 50 relations pour plus d'un millier de tables. Autant dire que les relations ne sont pas la première raison du déploiement du SGBDR.
L'avantage non négligeable est que le jour où vous souhaiterez déployer un client web (utile pour les conseils communautaire ou municipaux lors de la consultation de plan ^^), votre SGBDR sera déployé.
Point noir, l'administration du SGBDR comme le souligne Bruno.
art X I. Déclaration des Droits de l’Homme et du Citoyen 1789
La libre communication des pensées et des opinions est un des droits les plus précieux de l’Homme : tout Citoyen peut donc parler, écrire, imprimer librement, sauf à répondre de l’abus de cette liberté, dans les cas déterminés par la Loi.
Hors ligne
#8 Tue 13 September 2011 11:32
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3199
- Site web
Re: SGBD: quelles solutions pour quelles taille?
Bonjour
cela signifie t -il que mon système n'a pas besoin d'un SGBDR?
Non, le SGBDR EST LE système.
Pour obtenir une telle information (même si elle est volontairement fantaisiste) avec un SIG classique il vous faudra acheter un intégrateur de données cadastrale, connaître le modèle de données sous-jacent généré (ce qui en cas de solution payante est pas toujours évident) pour construire la requête. Et au final sans que l'utilisateur le voit il existe un SGBDR au sens pauvre du terme dans le logiciel SIG.
Alors qu'en possédant un SGBDR digne de ce nom vous maîtrisez le MCD, vous construisez une requête et à partir de là vous générez un joli shape (par exemple) que votre logiciel SIG pourra exploiter.
Ne confondez pas serveur, et SGBDR. Ce n'est pas parce que votre SGBDR sera basé sur une architecture client/serveur que tout le monde pourra venir faire une requête selon ses besoins.
Si je simplifie un peu, le SGBR permet d'interroger les données, le logiciel SIG de les cartographier.
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#9 Tue 13 September 2011 11:36
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3199
- Site web
Re: SGBD: quelles solutions pour quelles taille?
Bonjour,
@pierre
Autant dire que les relations ne sont pas la première raison du déploiement du SGBDR.
Le R signifie relationnel, cette utilisation en tant que stockage de table simple est certes possible mais réductrice.
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#10 Tue 13 September 2011 11:45
- PaulH
- Participant assidu
- Lieu: Nantes
- Date d'inscription: 1 Aug 2007
- Messages: 463
Re: SGBD: quelles solutions pour quelles taille?
Je comprends parfaitement le rôle d'un SGBDR et de ses utilisations.
Mes interrogations se situent plus sur la partie amont/structuration de l'ensemble des données de ma collectivité.
Ai-je besoin d'un SGBDR avec les données que je possède et selon les perspectives de développement?
Paul Hedin
ex-luern
Hors ligne
#11 Tue 13 September 2011 11:58
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1554
Re: SGBD: quelles solutions pour quelles taille?
Bonjour
cela signifie t -il que mon système n'a pas besoin d'un SGBDR?
Non, le SGBDR EST LE système.
Pour obtenir une telle information (même si elle est volontairement fantaisiste) avec un SIG classique il vous faudra acheter un intégrateur de données cadastrale, connaître le modèle de données sous-jacent généré (ce qui en cas de solution payante est pas toujours évident) pour construire la requête. Et au final sans que l'utilisateur le voit il existe un SGBDR au sens pauvre du terme dans le logiciel SIG.
Alors qu'en possédant un SGBDR digne de ce nom vous maîtrisez le MCD, vous construisez une requête et à partir de là vous générez un joli shape (par exemple) que votre logiciel SIG pourra exploiter.
Ne confondez pas serveur, et SGBDR. Ce n'est pas parce que votre SGBDR sera basé sur une architecture client/serveur que tout le monde pourra venir faire une requête selon ses besoins.
Si je simplifie un peu, le SGBR permet d'interroger les données, le logiciel SIG de les cartographier.
Bonjour,
Je ne saurai trop abonder dans le sens de cette réponse.
La mise en place d'un SGBD spatial garantira la pérennité du projet et son evolutivité (il n'y a qu'a songer a toutes les fonctions offertes par Postgis (ou Spatialite dans une moindre mesure) pour assurer des traitements spatiaux tres complexes, si le besoin s'en fait sentir).
Le ticket d'entree est un peu plus important qu'en travaillant avec des fichiers "a plat", mais la solution est tellement plus robuste et évolutive que ca vaut le coup.
Suivant la complexité et la volumétrie, il me semble que deux solutions sortent du lot:
• Postgis (on ne le presente plus)
• Spatialite (qui a l'enorme avantage de tout stocker dans un seul fichier exploitable de la meme facon sur toutes les plateformes)
Nicolas
En ligne
#12 Tue 13 September 2011 12:34
- CyrilA
- Juste Inscrit !
- Date d'inscription: 17 Feb 2010
- Messages: 4
Re: SGBD: quelles solutions pour quelles taille?
Je comprends parfaitement le rôle d'un SGBDR et de ses utilisations.
Mes interrogations se situent plus sur la partie amont/structuration de l'ensemble des données de ma collectivité.
Ai-je besoin d'un SGBDR avec les données que je possède et selon les perspectives de développement?
Il semble que constituer un SGBDR est pour toute collectivité un choix stratégique...
J'aurai tendance à dire oui
Aujourd'hui, peu de données, donc maitrise assez facile du modèle (très subjectif...).
Pour moi, il est plus facile de constituer un SGBD coeur le plus tot possible
Que risque-t-on à laisser les applications en l'état ?
Une hétérogéité de données de plus en plus fortes. Chaque composante métier souhaitera approfondir et rajouter des informations spécifiques à sa base.
De ce fait, il sera de plus en plus complexe de constituer un SGBD centralisé
Inversement, je réalise mon SGBD très tôt...
Je suis maître de mes données, je peux ainsi les partager avec l'ensemble des acteurs métiers, je peux également enrichir mon modèle avec de nouvelles informations. Je peux proposer une mutualisation de données pour différents services (exemple : référentiel de rues, d'adresses, de parcelles). Je simplifie les actions de mises à jour.
Voilà mon opinion ^^
Bonne réflexion
Hors ligne
#13 Tue 13 September 2011 13:40
- PaulH
- Participant assidu
- Lieu: Nantes
- Date d'inscription: 1 Aug 2007
- Messages: 463
Re: SGBD: quelles solutions pour quelles taille?
Merci bcp. vos opinions m'aident bcp à avancer.
Paul Hedin
ex-luern
Hors ligne
#14 Tue 13 September 2011 14:34
Re: SGBD: quelles solutions pour quelles taille?
Bonjour,
je ne travaille pas dans une collectivité mais dans une association de 25 salariés.
J'ai eu la chance de pouvoir mettre en œuvre PostGis il y a 5 ans. La motivation initiale était la consolidation des données produites et utilisées dans un modèle relationnel pour en favoriser l'exploitation.
La mise en place très en amont du SGBD, avec peu d'utilisateurs directs (1 puis 2 puis 15) a permis des évolutions conséquentes de l'utilisation des données (reporting, accès concurrents en édition avec QGis, diffusion de données, saisie contrôlée). Le SGBD est maintenant au cœur du SI et nous y connectons divers outils pour diverses applications.
Sans cet outil en place, nous nous serions peut-être interdit certaines possibilités, car la restructuration du SI a posteriori aurait été beaucoup plus complexe.
Bonne continuation,
Mathieu BOSSAERT
Association GeoRezo
Hors ligne
#15 Wed 17 April 2013 18:46
- hess
- Juste Inscrit !
- Date d'inscription: 20 Nov 2012
- Messages: 2
Re: SGBD: quelles solutions pour quelles taille?
il existe principalement les SGBD de type hiérarchique, de type réseau ou codasyl, de type relationnel et de type objet. lequel des types est le plus utiliser pour les SGBD à cartouche spatial en d'autre terme dans la conception des SIG?
Hors ligne
#16 Thu 18 April 2013 10:01
- Patrice
- JeSuisCharlie
- Date d'inscription: 16 Sep 2005
- Messages: 4794
Re: SGBD: quelles solutions pour quelles taille?
Hello Luern
Une petite remarque ...
Suivant la complexité et la volumétrie, il me semble que deux solutions sortent du lot:
• Postgis (on ne le presente plus)
• Spatialite (qui a l'enorme avantage de tout stocker dans un seul fichier exploitable de la meme facon sur toutes les plateformes)
Je crois que tu es dans une petite collectivite donc la volumetrie n'est pas un probleme !
Mais au niveau d'un departement ou grosse collectivite, lorsque tu atteins une volumetrie de l'ordre
de UN million d'objets dans une table spatiale (ou plus) et en plus x N tables, le choix du SGBD spatial va etre tres restreint ...
GeoBye, Pat
(Autodesk Expert Elite Team)
Hors ligne
#17 Thu 18 April 2013 12:00
Re: SGBD: quelles solutions pour quelles taille?
Hello Luern
Une petite remarque ...Suivant la complexité et la volumétrie, il me semble que deux solutions sortent du lot:
• Postgis (on ne le presente plus)
• Spatialite (qui a l'enorme avantage de tout stocker dans un seul fichier exploitable de la meme facon sur toutes les plateformes)
Je crois que tu es dans une petite collectivite donc la volumetrie n'est pas un probleme !
Mais au niveau d'un departement ou grosse collectivite, lorsque tu atteins une volumetrie de l'ordre
de UN million d'objets dans une table spatiale (ou plus) et en plus x N tables, le choix du SGBD spatial va etre tres restreint ...
GeoBye, Pat
+1, attention à spatialite qui n'est pas multiutilisateur.. dès qu'utilisateur fait des éditions, le fichier est locké. Donc très bien pour des bases (même grandes) mono utilisateur ou lecture seule. Pour des applis de saisie, un mode client serveur postgis est idéal.
Chez nous, les deux se complètent très bien, et on a uin plugin dans qgis 'offline editing' qui prend des données et les passe en spatialite. pratique, mais parfois buggé.
Depuis cette année, FME gère bienles bases spatialite au formalisme compatible QGIS. Très puissant pour extraire des données en masse.
Un défaut pour l'instant, on ne peut pas générer des index attributaires depuis FME (bug signalé), alors que c'est possible pour sqlite.
Hors ligne