Triggers, Rules, and Stored Procedures
Now we??™re in dangerous territory. Let it be known that you should probably have a
good reason to use triggers, rules, or stored procedures for anything terribly complicated.
That is not to say that they have no purpose; they can be lifesavers. But they
should be used to address a specific problem or concern, such as the following:
??? A complicated process that involves searching through lots of data (such as
OLAPor log analysis) can be much faster if offloaded to the database server. As
always, profiling is key; premature optimization can cost you execution speed,
not just developer time.
??? Concerns that have little to do with the application logic, such as audit logs, can
usually be safely moved to the database as triggers.
??? PostgreSQL can use rules to create updateable views. Unfortunately, this is currently
the only way to get updateable views.
Advanced Database Features | 115
??? When using Postgres large objects, you should use a trigger to delete the large
object when the corresponding record (containing the LOB??™s OID) is deleted.
Consider this a form of referential integrity.
??? Extended or non-native types will use stored procedures for access. PostGIS, a
geospatial database for Postgres, uses functions to manage spatial data and
indexes.
??? The TSearch2 library, integrated into PostgreSQL 8.3 and later, uses functions to
access full-text indexing functions.
Pages:
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182