+ linkid="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