rdelaage/postgresql
1
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-07-16 14:31:08 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs: improve description of how to handle multiple databases

Browse Source 
This is a redesign of the intro to the managing databases chapter.

Discussion: https://postgr.es/m/159586122762.680.1361378513036616007@wrigleys.postgresql.org

Author: David G. Johnston

Backpatch-through: 9.5
This commit is contained in:
Bruce Momjian 2020-08-21 20:23:09 -04:00
parent 1e6edbfa23
commit ac0ad75bf7
1 changed files with 35 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
doc/src/sgml/manage-ag.sgml
View File

@ -33,21 +33,41 @@
</para> </para>
<para> <para>
When connecting to the database server, a client must specify in When connecting to the database server, a client must specify the
its connection request the name of the database it wants to connect database name in its connection request.
to. It is not possible to access more than one database per It is not possible to access more than one database per
connection. However, an application is not restricted in the number of connection. However, clients can open multiple connections to
connections it opens to the same or other databases. Databases are the same database, or different databases.
physically separated and access control is managed at the Database-level security has two components: access control
connection level. If one <productname>PostgreSQL</productname> server (see <xref linkend="auth-pg-hba-conf"/>), managed at the
instance is to house projects or users that should be separate and connection level, and authorization control
for the most part unaware of each other, it is therefore (see <xref linkend="ddl-priv"/>), managed via the grant system.
recommended to put them into separate databases. If the projects Foreign data wrappers (see <xref linkend="postgres-fdw"/>)
or users are interrelated and should be able to use each other's allow for objects within one database to act as proxies for objects in
resources, they should be put in the same database but possibly other database or clusters.
into separate schemas. Schemas are a purely logical structure and who can The older dblink module (see <xref linkend="dblink"/>) provides a similar capability.
access what is managed by the privilege system. More information about By default, all users can connect to all databases using all connection methods.
managing schemas is in <xref linkend="ddl-schemas"/>. </para>
<para>
If one <productname>PostgreSQL</productname> server cluster is planned to contain
unrelated projects or users that should be, for the most part, unaware
of each other, it is recommended to put them into separate databases and
adjust authorizations and access controls accordingly.
If the projects or users are interrelated, and thus should be able to use
each other's resources, they should be put in the same database but probably
into separate schemas; this provides a modular structure with namespace
isolation and authorization control.
More information about managing schemas is in <xref linkend="ddl-schemas"/>.
</para>
<para>
While multiple databases can be created within a single cluster, it is advised
to consider carefully whether the benefits outweigh the risks and limitations.
In particular, the impact that having a shared WAL (see <xref linkend="wal"/>)
has on backup and recovery options. While individual databases in the cluster
are isolated when considered from the user's perspective, they are closely bound
from the database administrator's point-of-view.
</para> </para>
<para> <para>