mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-24 15:07:19 +02:00
docs: improve description of how to handle multiple databases
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:
parent
1e6edbfa23
commit
ac0ad75bf7
@ -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>
|
||||||
|
Loading…
Reference in New Issue
Block a user