Source of: /manual/en/security.database.design.php
<?php
include_once $_SERVER['DOCUMENT_ROOT'] . '/include/shared-manual.inc';
$TOC = array();
$PARENTS = array();
include_once dirname(__FILE__) ."/toc/security.database.inc";
$setup = array (
'home' =>
array (
0 => 'index.php',
1 => 'PHP Manual',
),
'head' =>
array (
0 => 'UTF-8',
1 => 'en',
),
'this' =>
array (
0 => 'security.database.design.php',
1 => 'Designing Databases',
),
'up' =>
array (
0 => 'security.database.php',
1 => 'Database Security',
),
'prev' =>
array (
0 => 'security.database.php',
1 => 'Database Security',
),
'next' =>
array (
0 => 'security.database.connection.php',
1 => 'Connecting to Database',
),
);
$setup["toc"] = $TOC;
$setup["parents"] = $PARENTS;
manual_setup($setup);
manual_header();
?>
<div id="security.database.design" class="sect1">
<h2 class="title">Designing Databases</h2>
<p class="simpara">
The first step is always to create the database, unless you want to use
one from a third party. When a database is created, it is
assigned to an owner, who executed the creation statement. Usually, only
the owner (or a superuser) can do anything with the objects in that
database, and in order to allow other users to use it, privileges must be
granted.
</p>
<p class="simpara">
Applications should never connect to the database as its owner or a
superuser, because these users can execute any query at will, for
example, modifying the schema (e.g. dropping tables) or deleting its
entire content.
</p>
<p class="simpara">
You may create different database users for every aspect of your
application with very limited rights to database objects. The most
required privileges should be granted only, and avoid that the same user
can interact with the database in different use cases. This means that if
intruders gain access to your database using your applications credentials,
they can only effect as many changes as your application can.
</p>
<p class="simpara">
You are encouraged not to implement all the business logic in the web
application (i.e. your script), instead do it in the database schema
using views, triggers or rules. If the system evolves, new ports will be
intended to open to the database, and you have to re-implement the logic
in each separate database client. Over and above, triggers can be used
to transparently and automatically handle fields, which often provides
insight when debugging problems with your application or tracing back
transactions.
</p>
</div><?php manual_footer(); ?>
