Hi Vishy,

> Yu said..Use triggers to enforce database consistency..

And I will expand on that too. Also use foreign key and unique
constraints where applicable.

>
> Now,from application point of view..all business objects validatae
> data as well as enforce business rules..
> Our database team says triggers need to be used since if someone
> (support team for the software) access a database directly and
> changes data in the table directly..then trigger should be fired to
> enforce other changes that should take place..i think this is
> wrong..why should anyone be allowed such an access

Firstly there is nothing wrong with having some sort of data
abstraction layer, in fact it is often the best way to do it. What
you do NOT want to happen is to have the validation code inside your
application because as others have said, you may be required to port
some part of your application to another language or put a html front
end for it, and the last thing you want to be doing is to maintain
two sets of pseudocode-identical validation code.

Secondly, consider Murphy's law. If it is possible for the database
to be left in an inconsistent state by a rogue program, it is just a
matter of time until someone doesn't think about some business rule
when writing an interface. Creating triggers to enforce the business
rules can literally send the exception to the interface to deal with.
Even if our support team stuff around in IBOConsole etc, they can not
accidentally leave the system in a state that would confuse the
applications.

>...or is this an
> industry practice...maybe provide views through which changes can
> take place..

Stored procedures are a good way to abstract the table design from
the function. For example, you could create a procedure
SP_Create_Customer and pass into it all the information required to
create a customer. Internally it may run 5 or 6 queries to actually
add a customer.

Adam