Le portail francophone de la géomatique

Bonjour,

Organiser en schema est une bonne idee ! il faut la garder.
Pour que les tables et vues d'un schema soient "comprise" de la base de données sans avoir a utiliser le nom qualifié "schema.table" lors d'une requete, on peut utiliser la variable SEARCH_PATH de postgresql. Celle-ci définit la liste des schemas "par defaut", que la base cherchera automatiquement lors d'une requete.

C'est tres pratique, mais il y a une limitation: les noms des objets (tables, vues, fonctions, etc.) doivent etre uniques entre les schemas, sinon, on peut se retrouver avec des comportements curieux, exemple:

Prenons deux schemas:  schema A, table T1, schema B, table T1.
On ajoute ces schemas a la variable search_path:

set search_path to a, b, public, "$user";

si on ecrit:

select * from T1;

ca sera interprété par la base comme:

select * from A.T1,
car le schema A est defini en premier dans la liste des search path.
Il faut donc veiller a utiliser des noms uniques pour ses objets.

Concernant Mapguide OS, que voulez-vous dire par "le schema n'est pas fonctionnel" ? les tables ne sont pas vues si elles sont dans des schemas ?
Les metadonnees de geometry_columns sont elles bien renseignees ?
En mettant a jour la variable search_path, Mapguide devrait s'y retrouver.
Sinon, ecrire a la communauté pour se plaindre !
Une application qui se branche sur des bases de données mais qui ne gere pas les schemas, c'est tout de meme tres bizarre !

Nicolas

Dernière modification par Nicolas Ribot (Sat 17 December 2011 11:47)

Quand je dis pas fonctionnel, j'arrive a me connecter à la BDD, mais je n'arrive pas accéder a la colonne de géométrie. (the_geom)
Mapguide OS permet d'utiliser différents schémas puisque qu'il faut le spécifier dans le provider FDO (il est nommé dans maestro "magasin de données").

Dans la table "geometry_columns" j'ai bien la liste des tables et des schema.

Par contre dans les schémas que j'ai créé, je n'ai ni de table "geometry_columns", ni de table "spatial_ref_sys". Je ne les retrouvent que dans le schema "public"

Normal, ces tables doivent etre dans le schema public, en un seul exemplaire: elles decrivent metadonnees et systemes de projection pour toute la base.

Bonjour,
Je reste sur ce même post pour le compléter mais aussi pour poser une petite question.
Je bosse également sur les schemas.et comme smile, j'ai eu le souci du "public" avec le système avec lequel je travaille.
J'ai mis dans le search_path les schemas (set search_path to a, b, public) mais tout se perd à chaque connexion, j'ai donc rajouter ALTER nom_user SET search_path to a, b, public.
Mais là apparait un autre soucis, c'est que cette commande ne sert que pour une base de données alors que le search_path sert pour le serveur postgis. Je m'explique :
pour une bd A avec un schemaA1 et un schemaA2 et une bd B avec un schemaB2,
  - si je lance mon SQL sur ma baseA ALTER postgres SET search_path to shemaA2 , shemaA1 , public. Mon search_path est ainsi shemaA2 , shemaA1 , public (show search_path pour voir ce qu'il y a dans le search_path)
  - Pour ajouter le schemaB2 je lance ma commande "ALTER postgres SET search_path to shemaA2 , shemaA1 , public, schemaB2". Mais postgis me dit "Le schemaB2 n'existe pas".
- Donc je le relance sur la seconde base "ALTER postgres SET search_path to schemaB2 , public", mais là mon search_path n'est plus que "shemaB2 , public"

Ma question est, avec vous une commande pour ajouter tous les schemas de toutes les bases?

Pour palier ce problème, j'ai créé une base vide nommée SCHEMA avec ou je créée tous les schemas de mes bases et je lance la ligne "ALTER postgres SET search_path to shemaA2 , shemaA1 , public, schemaB2". Et là avec show search_path on voit bien que tous les schemas sont bien saisis. Et tout fonctionne bien. Mais ça n'est pas vraiment optimal.

Si quelqu'un a la solution je suis preneur.

Je ne peux pas tester aujourd'hui... vive les rtt! Mais dès lundi je me mets au boulot! C'est vrai que c'est plus logique de faire avec les databases, mais je n'avais pas trouvé cette commande.

Par contre pour le template, aucune base n'a les mêmes schémas, donc au premier abords, ça ne va pas trop me servir. Mais je vais creuser un peu.

Merci bcp

Ah ok, si c'est ça, c'est déjà fait, avec un template postgis, qui comporte un schéma public avec toutes les fonctions postgis, et les tables spatial_refsys et geometry_columns. Et je le prends par défaut à chaque création de base.

Ne reste plus qu'à tester ce que Nicolas m'a conseillé

Merci

Bonjour,

la documentation de PostgreSQL est très bien faite, n'hésitez pas à la consulter tirer un bénéfice de vos erreurs et pour exploiter au mieux les capacité de votre outil.

http://docs.postgresql.fr/9.0/ddl-schemas.html

Dans la clause WHERE de votre requête, vous avez prefixé deux fois le nom de la colonne concernée :

WHERE ore.name.name = 'U';

Ça se traduit comme ceci : la colonne "name" de la table "name" contenue dans le schéma "ore" est égale à 'U'.

Bon week-end,