- linkend="plpython">.
-
-
-
There are several ways that stored procedures are really- helpful:
-
-
-
-
To centralize data validation code into the- database
-
-
Your system may use client software written in several- languages, perhaps with a web application
- implemented in PHP, a server application
implemented
- in Java, and a report writer
implemented in Perl.
- In the absence of stored procedures, you will likely find that data
- validation code must be implemented multiple times, in multiple
- languages, once for each application.
-
-
By implementing data validation in stored procedures,- running in the database, it can behave uniformly for all these
- systems, and you do not need to worry about synchronizing
- validation procedures across the languages.
-
-
-
-
Reducing round trips between client and server-
-
-
A stored procedure may submit multiple queries, looking up- information and adding in links to additional tables. This takes
- place without requiring that the client submit multiple queries,
- and without requiring any added network traffic.
-
-
-
As a matter of course, the queries share a single- transaction context, and there may also be savings in the
- evaluation of query plans, that will be similar between invocations
- of a given stored procedure.
-
-
-
For instance, if you are commonly checking the TLD on domain- names, you might create a stored procedure for this purpose, and so
- be able to use queries such as select domain, tld(domain)
- from domains; instead of having to put verbose code
- using substr() into each query.
-
-
-
It is particularly convenient to use scripting languages- like Perl, Tcl, and Python to grovel through strings
- since they are designed for text processing.
-
-
The binding to the R statistical language allows- implementing complex statistical queries inside the database,
- instead of having to draw the data out.
-
-
-
Increasing the level of abstraction-
-
If data is accessed exclusively through stored procedures,- then the structures of tables may be changed without there needing
- to be any visible change in the API used by programmers. In some
- systems, users are only allowed access to
- stored procedures to update data, and cannot do direct updates to
- tables.
-
-
-
-
-
-
-
-
These benefits build on one another: careful use of stored- procedures can simultaneously improve reliability and performance,
- whilst simplifying database access code and improving portability
- across client platforms and languages. For instance, consider that
- a stored procedure can cheaply query tables in the database to
- validate the correctness of data provided as input.
-
-
Instead of requiring a whole series of queries to create an- object, and to look up parent/subsidiary objects to link it to, a
- stored procedure can do all of this efficiently in the database
- server, improving performance, and eliminating whole classes of
- errors.
-
-
-
-
-
Triggers
-
-
-
-
-
Triggers allow running a function either before or after- update (INSERT, DELETE,
- UPDATE) operations, which can allow you to do
- some very clever things.
-
-
-
-
-
Instead of explicitly coding validation checks as part of a- stored procedure, they may be introduced as BEFORE
- triggers. The trigger function checks the input values, raising an
- exception if it finds invalid input.
-
-
Note that this is how foreign key checks are implemented in-
PostgreSQL; when you define a foreign
- key, you will see a message similar to the following:
-
-NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s)
-
-
-
In some cases, it may be appropriate for a trigger function- to insert data in order to make the input valid. For
- instance, if a newly created object needs a status code in a status
- table, the trigger might automatically do that.
-
-
-
-
One may use AFTER triggers to monitor updates to- vital tables, and INSERT entries into log tables to
- provide a more permanent record of those updates.
-
-
-
-
The RServ replication system uses- AFTER triggers to track which rows have changed on the
- master
system and therefore need to be copied over to
- slave
systems.
-
- CREATE TRIGGER "_rserv_trigger_t_" AFTER INSERT OR DELETE OR UPDATE ON "my_table"
- FOR EACH ROW EXECUTE PROCEDURE "_rserv_log_" ('10');
-
-
-
-
-
-
Notice that there are strong parallels between what can be- accomplished using triggers and stored procedures, particularly in
- regards to data validation.
-
-
Conclusion
projects / postgresql.git / commitdiff