Annonce
L'appel à participation est ouvert jusqu'au 19 janvier 2025!
#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: 1554
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
En 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: 1554
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
En ligne
