#1 Mon 18 May 2020 11:18
- thomas.bagot
- Participant occasionnel
- Date d'inscription: 18 May 2020
- Messages: 10
BD Geo ou schema de donnee Geo dans base de donnees
Bonjour,
Je me pose une question dans la gestion des base de donnĂ©es. J'ai plusieurs base de donnĂ©es thĂ©matiques qui utilisent toutes des donnĂ©es gĂ©ographiques parfois les mĂȘmes ou parfois diffĂ©rentes donnĂ©es gĂ©ographiques. Je me demande si je dois crĂ©er un schĂ©ma de donnĂ©es gĂ©ographiques par base de donnĂ©es, ou alors une base de donnĂ©es gĂ©ographiques pour toutes les bases de donnĂ©es ?
En vous remerciant d'avance, Thomas Bagot
Hors ligne
#2 Tue 19 May 2020 10:00
- Edouard Hyvernat
- Participant occasionnel
- Lieu: Vernon
- Date d'inscription: 24 Jan 2011
- Messages: 46
Re: BD Geo ou schema de donnee Geo dans base de donnees
Bonjour,
Je ne sais pas avec quel SGBD vous travaillez mais dans le cas de PostgreSQL, la partie géo est gérée par une extension de cet outil qui se nomme Postgis et qui s'active (si installée) comme une extension classique, à savoir au niveau d'une base de donnée.
Par défaut, les composants propre à Postgis se retrouvent dans le schéma public.
Mais ce n'est pas parce que Postgis est actif pour une base de données, que je ne peux pas avoir des tables dans différents schémas qui ne soient pas avec une dimension géographique.
A mon sens, plutÎt que de vous poser la question par rapport à la dimension géographique ou non de vos données, organisez plutÎt vos données en fonction de leur thématique dans différents schémas, activez Postgis au niveau de la base de donnée et ensuite vous peuplez vos schémas avec différentes tables qu'elles soient géo ou non.
En tout cas c'est ainsi que je fonctionne ![]()
NĂ©anmoins, si vous ĂȘtes contraint par la volumĂ©trie de vos donnĂ©es et que vous travaillez toujours sur le mĂȘme rĂ©fĂ©rentiel gĂ©o (par ex le parcellaire cadastral ou les limites de communes), vous pouvez toujours crĂ©er un schĂ©ma spĂ©cifique avec vos donnĂ©es gĂ©o de rĂ©fĂ©rence et vous crĂ©ez autant de vue que nĂ©cessaire par une jointure spatiale adĂ©quate ou par le biais d'hĂ©ritage entre tables afin de limiter le travail de gĂ©orĂ©fĂ©rencement de vos donnĂ©es.
Et je pense que le raisonnement est le mĂȘme si vous travaillez sous Oracle ou SQL Server.
Ces conseils mĂ©riteraient d'ĂȘtre affinĂ©s en fonction de vos problĂ©matiques et je ne prĂ©tends pas ĂȘtre un spĂ©cialiste non plus dans ce domaine !
Hors ligne
#3 Tue 19 May 2020 10:29
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1566
Re: BD Geo ou schema de donnee Geo dans base de donnees
Bonjour,
MĂȘme conseil que celui d'Edouard:
Mettez vos données dans une base unique (le terme "base de données" est souvent utilisé dans le monde postgres pour désigner l'entrepot physique: une instance créée sur votre cluster postgresql).
Vous pourrez organiser vos jeux de données par schéma et factoriser ainsi certaines données géographiques (par ex: une seule table "commune" avec les communes géo, et des liens (ou vues comme le disait Edouard) entre des tables et cette table commune.
L'avantage de tout mettre dans une base unique est d'ouvrir le sytĂšme pour le futur: vous ne savez pas encore tous les usages que vous ferez de vos donnĂ©es, mais en les mettant au mĂȘme endroit, vous facilitez les croisements et requetes que vous pourrez faire sur vos donnĂ©es.
Concernant la volumétrie potentielle des données: soyez rassuré: PG peut stocker des centaines de milliards de coordonnées, pour des volumes de plusieurs centaines de To. (je travaille avec un client dont la BD contient 520 schéma, ~ 14000 tables, dont certaines comme les parcelles ou les polygones OSM font plusieurs centaines de Go pour environ 100M d'objets géo)
Nico
Hors ligne
#4 Tue 26 May 2020 11:14
- thomas.bagot
- Participant occasionnel
- Date d'inscription: 18 May 2020
- Messages: 10
Re: BD Geo ou schema de donnee Geo dans base de donnees
Bonjour,
Merci beaucoup pour vos réponses, je comprends mieux la logique. Il est donc préférable d'utiliser une base de données avec des schémas par thématique plutÎt que différentes base de données par thématique, est-ce bien cela ? Pour les données géo on peut imaginer avoir un schéma géo pour les données géo communes aux différents schémas et des données géo thématiques stockés au sein de leurs schémas.
En ce qui concerne le rĂŽle des base de donnĂ©es, dans quel cas crĂ©er plusieurs base de donnĂ©es pour un mĂȘme serveur ?
En vous remerciant d'avance
Bonne journée
Thomas Bagot
Hors ligne
#5 Tue 26 May 2020 11:32
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1566
Re: BD Geo ou schema de donnee Geo dans base de donnees
Bonjour,
Oui c'est ca: une BD unique, plusieurs schémas pour organiser, et suivant l'architecture de ses données, la perf, etc:
Par exemple si plusieurs tables font références à des communes, on peut soit stocker la géométrie des communes dans chaque table avec un champ geometry (mais on duplique les données), ou bien faire une seule table commune (code_insee, geom) et faire des liens (foreign key par ex) entre les tables et la partie geo des communes.
Pourquoi crĂ©er plusieurs BD ? il peut y avoir pleins de raisons: par ex avoir une BD "prod" et "dev", qui sont les mĂȘmes mais une (dev) permet de faire les tests etc. sans toucher Ă la BD prod utilisĂ©e par des applications par ex.
Ca peut etre également pour stocker d'autres infos qui n'ont rien a voir avec la premiÚre BD (gestion du personnel par ex; mais meme dans ce cas, je suis partisan d'une BD unique, bien rangée).
Dans mon exemple personnel, j'ai plusieurs BD sur le mĂȘme cluster (PG 9.6 par ex) qui sont des copies partielles (ou bases de test) pour mes diffĂ©rents clients. Et je constate souvent qu'un client a une seule BD sur son cluster (enfin, a part les BD systĂšmes comme template0, template1...).
Enfin, rien n'empeche d'organiser ses donnĂ©es en pleins de BD diffĂ©rentes, par thĂšme. Mais lĂ , ca sera plus difficile et bien moins performant de faire des requĂȘtes sur des donnĂ©es prĂ©sentes dans les diffĂ©rentes bases (on peut le faire avec FDW postgres_fdw, mais la perf n'est pas la mĂȘme)
Nicolas
Hors ligne

