Re: brutally simple question - number of triggers on a table
- From: sandeep dubey <dubey.sandeep@xxxxxxxxx>
- To: mark.powell@xxxxxxx
- Date: Fri, 22 Apr 2005 10:37:39 -0400
The place where I work, doesn't have a single trigger. The application
architect is of strong opinion that when business logic is stored in
the database in form of triggers when 1000+ transactions hitting the
same table at sime time, database cannot perform. Here we have rigid
SLA requirements. All business logic is stored in middleware in
application which in turn clustered and load balanced. Any backdoor
data updates (from SQL) passes through strong QA audit.
Sandeep Dubey
On 4/22/05, Powell, Mark D <mark.powell@xxxxxxx> wrote:
>=20
> The basic question was to use database table level triggers or not?
>=20
> Every action that an application takes should leave the data in a valid
> consistent state. The reality is that the only way to guarantee enforcem=
ent
> of complex business rules and data relationships is often to encode these
> rules into the database. This is done not just with PK, UK, and FK
> constraints but also using database table level triggers especially where=
an
> event driven process must take place.
>=20
> If the requirement exists that for every change made to Table_A a record =
of
> the change must be kept you do not trust the changing application to reco=
rd
> the change. You encode this into a trigger and the trigger updates an au=
dit
> or history table.
>=20
> Triggers are also useful to enforce referential integrity to a remote
> database object.
>=20
> Every table does not need a trigger. Most in fact probably do not, but
> there are times when database level table triggers are the only true
> reliable solution to enforcing application data integrity.
>=20
> IMHO -- Mark D Powell --
>=20
>=20
> --
> //www.freelists.org/webpage/oracle-l
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
