Vous utilisez un schéma autre que public dans PostGIS?

Je suis en train de configurer une nouvelle installation de PostGIS 2.0.2 et PostgreSQL 9.1.6 sur Ubuntu. J'ai récemment rencontré des informations indiquant que l'utilisation du schéma public pour stocker toutes les données n'est pas une bonne idée.

Pour cette raison, j'ai mis en place un schéma appelé données et me suis fait propriétaire, mais est-ce une bonne idée?

Mes préoccupations sont les suivantes:

1. En plus de définir le propriétaire, je devrais peut-être faire attention aux choses sur l'onglet Privilèges lors de la création de ce nouveau schéma (via pgAdmin III);
2. Je ne peux pas obtenir les mêmes avantages en stockant mes données dans le schéma public et en vidant toutes les données dans un schéma séparé avant de faire une sauvegarde / restauration (cela permettrait d'économiser quelques touches lors de l'utilisation d'ogr2ogr); et
3. Je peux rencontrer des problèmes en ne disposant pas des tables et des vues PostGIS par défaut dans mon nouveau schéma de données (elles se trouvent dans le schéma public de la même base de données).

Ceci est désormais résolu sur le site officiel dans une page intitulée Déplacer l'extension PostGIS vers un autre schéma . La bonne méthode consiste à installer l'extension dans public. C'est la seule option. L'extension ne prend plus en charge la relocalisation. La prochaine chose est d'exécuter les commandes suivantes, (copiées à partir du site),

UPDATE pg_extension 
  SET extrelocatable = TRUE 
    WHERE extname = 'postgis';

ALTER EXTENSION postgis 
  SET SCHEMA postgis;

Lorsque vous activez spatialement une base de données PostGIS, les fonctions, la table SRS et les vues pertinentes sont placées dans le schéma public, comme vous le dites. Cela ne signifie pas que tout ou partie de vos propres tables spatiales doivent être dans le même schéma public. PostGIS continuera de travailler sur toutes les données spatiales dans les "nouveaux" schémas.

En fait, je place généralement mes tables spécifiques à l'application dans un schéma distinct. De cette façon, si vous devez effectuer une mise à niveau de version majeure vers PostGIS, vous pouvez conserver vos sauvegardes et restaurations de table spécifiques à l'application en tant que procédure distincte de celle qui remplace les outils spatiaux.

Donc, je pense que tu vas bien. Enfin, au cas où vous ne l'auriez pas déjà fait, c'est une bonne idée d'ajouter le nouveau schéma au chemin de recherche:

ALTER DATABASE my_db SET search_path = gc, public;

1. L'une des stratégies organisationnelles possibles que vous pouvez créer avec des schémas est de permettre à un utilisateur de s'exécuter de manière rampante dans un schéma, mais d'être incapable d'encrasser les choses dans un autre. Donc, si vous souhaitez utiliser les schémas de cette manière, cela peut être fait dans l'onglet privilèges de pgAdmin. Mais il n'est pas obligatoire de le faire, donc si vous voulez simplement conserver les mêmes privilèges sur plusieurs schémas, c'est bien.

2. Sur la base des articles auxquels vous avez lié, le problème de garder tout en public est que lorsque vous sauvegardez des données, vous risquez d'obtenir des tables système et des relations mélangées avec vos données. Si vous déplacez toutes vos données vers un nouveau schéma, vous n'aurez plus jamais à vous en soucier.

3. Aucun problème. (Pour preuve, notez que vous n'avez pas besoin de spécifier public.spatial_ref_sys lorsque vous souhaitez rechercher la table SRS.)

Un conseil supplémentaire (peut-être que vous l'avez déjà rencontré). Vous voudrez probablement ajouter le schéma "data" au chemin de recherche par défaut de l'utilisateur. Quelque chose comme:

ALTER USER <your_user_name> SET search_path=public,data,$USER; 

Concernant votre point 2, vous devez parfois restaurer lorsque vous n'avez plus accès à la base de données d'origine. (C'est l'une des raisons des sauvegardes ...) afin que vous n'ayez pas la possibilité de déplacer vos données vers un schéma distinct lorsque vous en avez réellement besoin.

Nous utilisons le schéma public pour les résultats temporaires de la table d'analyse / dev, puis nous allons dans des schémas plus organisés (dossiers?) Pour une utilisation permanente.