PostgreSQLLa base de données la plus sophistiquée au monde.

Version anglaise

22. Administration des bases de données

Chaque instance d'un serveur PostgreSQL™ gère une ou plusieurs bases de données. Les bases de données sont donc le niveau hiérarchique le plus élevé pour organiser des objets SQL (« objets de base de données »). Ce chapitre décrit les propriétés des bases de données et comment les créer, les administrer et les détruire.

22.1. Aperçu

Un petit nombre d'objets, comme les rôles, les bases de données et les tablespaces, sont définis au niveau de l'instance et stockés dans le tablespace pg_global. À l'intérieur de l'instrance résident plusieurs bases de données, isolées les unes des autres mais pouvant accéder aux objets du niveau instance. Dans chaque base se trouvent plusieurs schémas contenant des objets comme les tables et les fonctions. La hiérarchie complète est donc : instance, base de données, schéma, table (et autre type d'objet comme une fonction).

Lors de la connexion au serveur de bases de données, un client doit indiquer le nom de la base dans sa demande de connexion. Il n'est pas possible d'accéder à plus d'une base par connexion. Néanmoins, les clients peuvent ouvrir plusieurs connexions à la même base ou à des bases différentes. La sécurité au niveau base a deux composants : le contrôle d'accès (voir Section 20.1, « Le fichier pg_hba.conf »), géré au niveau de la connexion, et le contrôle d'autorisation (voir Section 5.6, « Droits »), géré par le système GRANT. Les wrappers de données distantes (voir postgres_fdw) permettent aux objets d'une base d'agir comme proxy pour objets d'autres bases, voire instances. L'ancien module dblink (voir dblink) fournit des fonctionnalités similaires. Par défaut, tous les utilisateurs peuvent se connecter à toutes les bases en utilisant toutes les méthodes de connexion.

Si une instance PostgreSQL™ est prévue pour contenir des projets sans relation ou des utilisateurs qui devraient, en grande partie, n'être pas au courant des autres, il est recommandé de les placer dans des bases séparées et d'ajuster les contrôles d'autorisation et d'accès de façon approprié. Si les projets ou les utilisateurs sont liés, et de ce fait, doivent être capable d'utiliser les ressources des autres, ils doivent être placés dans la même base, mais probablement dans des schémas séparés ; cela fournit une structure modulaire avec une isolation des schémas et un contrôle des autorisations. Vous trouverez plus d'informations sur la gestion des schémas dans Section 5.8, « Schémas ».

Lorsque plusieurs bases peuvent être créées dans une même instance, il est conseillé de faire bien attention à ce que les bénéfices dépassent largement les risques et les limitations. En particulier, le fait d'avoir des journaux de transactions partagés (voir Chapitre 30, Fiabilité et journaux de transaction) a un impact sur les options de sauvegarde et de restauration. Bien que les bases individuelles de l'instance sont isolées du point de vue de l'utilisateur, elles sont fortement liées du point de vue de l'administrateur.

Les bases de données sont créées avec la commande CREATE DATABASE (voir la Section 22.2, « Création d'une base de données ») et détruites avec la commande DROP DATABASE (voir la Section 22.5, « Détruire une base de données »). Pour déterminer l'ensemble des bases de données existantes, examinez le catalogue système pg_database, par exemple

SELECT datname FROM pg_database;

La méta-commande \l du programme psql(1) et l'option en ligne de commande -l sont aussi utiles pour afficher les bases de données existantes.

[Note]

Note

Le standard SQL appelle les bases de données des « catalogues » mais il n'y a aucune différence en pratique.