La structuration PostgreSQL
Cette figure illustre la façon dont peut être organisée une base de données PostgreSQL.
La base de données postgres peut être utilisée comme espace de travail, on préférera cependant créer une base de données dédiée.
La collation se décompose en 2 parties :
Àarrive avant
B.
Les collationnements sont toujours liés au jeu de caractères utilisé.
Le charset
utilisé par une connexion à une base de données ne correspond pas à celui de la base de données
mais à celui demandé par le client connecté. La directive SQL SET NAMES charset; permet de configurer
celui-ci correctement. Une mauvaise attribution du charset
de connexion peut mener à des problèmes insolubles !
CREATE DATABASE test_utf8 ENCODING = 'UTF-8'
LC_CTYPE = 'fr_FR.UTF-8'
LC_COLLATE = 'fr_FR.UTF-8';
CREATE DATABASECREATE DATABASE test_posix TEMPLATE template0
ENCODING = 'ISO8859-15'
LC_CTYPE = 'POSIX' LC_COLLATE = 'POSIX';
CREATE DATABASEOn peut créer autant de schémas qu'on le désire dans une base de données.
Il est possible de définir finement des droits sur des schémas, ce qui justifie leur utilisation.
Un autre intérêt est de créer un schéma pour héberger des applications particulières devant être accessibles depuis la base de données de connexion et ce sans risque de collisions au niveau des noms.
L'utilisateur étant confiné à la base de données de la connexion courante, la notion d'adressage complet n'a un intérêt que pour des raisons de compatibilité.
Un schéma est comparable à un répertoire UNIX à la différence près qu'il est impossible d'y inclure des schémas (un répertoire pouvant contenir des répertoires).
Les noms utilisant en préfixe pg_ sont à éviter car ils peuvent correspondre à des objets du schéma pg_catalog.
CREATE SCHEMA mon_schema;DROP SCHEMA mon_schema;Si le but est de faire une application basique, le schéma public tel que défini par défaut sera suffisant. Dans des utilisations plus complexes il sera préférable de déclarer plusieurs schémas et de détruire le schéma public.
Il existe également d'autres d'objets tels que les rôles, les fonctions, les langages, ...
Le data_directory est à priori indiqué dans le fichier postgresql.conf, dans le cas contraire ce sera soit la variable d'environnement $PGDATA si indiquée au serveur, sinon le répertoire indiqué par l'option -D chemin/vers/stockage précisée lors du lancement du serveur.
cluster: utilisateurs, droits...
Contrairement aux vues classiques, les vues matérialisées nécessitent du stockage, c'est la raison pour laquelle cette nouvelle possibilité de TABLESPACE est offerte pour ce type de vue.
CREATE TABLESPACE nom_espace
LOCATION 'chemin/vers/répertoire';ALTER DATABASE ma_database
SET default_tablespace = nom_espace;Les éléments créés seront placés dans le répertoire correspondant à l'identifiant (OID) de la base de données dans le TABLESPACE visé.
\l+
\dn+
tablespaceprésents sur le système :
\db+
SELECT * FROM pg_namespace;
Il existe une multitude de manières d'organiser des bases de données, ainsi un système de fichiers de type Unix constitue une base de données hiérarchique, le concept de base de données orientée objet est une autre approche.