Hi Adam,

thanks a lot for such clear explanation..good learning for me..
Now,our application is being developed in windows forms,.net
based..our clients will always be desktop-based..Our architecture is..
UI layer,Business Layer(all the business objects and validation,and
rules),Data Access Layer and database..2-tier..multiple clients..and
one server.
Why rules and validation in business layer..simple i dont want to
make a network trip to database and do validation,when I can do it on
client,a smart client on which I will replicate some portion of
database,...so what yu r suggesting is to duplicate all the
validation and rules in database using triggers and stored
procedures..rite??..

regards
vishy

--- In firebird-support@yahoogroups.com, "Adam" <s3057043@y...> wrote:
> 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