--- In firebird-support@yahoogroups.com, "mlq97" <mlq@...> wrote:

>
> What is the perceived wisdom about where to put business rules for a
> simple app? (Into the database or the front end?)
>
> I'm planning a commercial Win32 (Firebird) database application which
> will mainly be used as a single user standalone program, with a small
> percentage of users using a networked workgroup version, so this is
> unlikely to ever need 3 tier architecture.

LOL, most of us have been around when words like "unlikely" or "no
chance" are tossed around.

Here is my advice for what it is worth. From time-to-time, you will be
asked to develop a new frontend. From time-to-time you will be asked
to support a new dbms backend. If your business rules live in your
GUI, it will be very difficult if you want to in the future support a
web interface or even a console interface or integration to other systems.

If it is in the database, then you will have a hard time easily
porting between database backends. But the database can do it a lot
quicker.

Consistency rules should be enforced in the database. All DBMS worth
considering have ample ability to do this. I prefer to have a data
abstraction layer that sits on top of the database. This can police
the business rules if you don't feel they should be in the database or
it must be duplicated for several dbms. In this case, the dbms becomes
secondary. It is little more than a mechanism of storing and
retrieving data. But if you have such a layer, then you can swap over
front ends without recoding your business rules.

But you should not be able to store inconsistent data. Your front end
shouldn't try, and even if it did try, your data abstraction layer
should refuse it, and if that too let it through, then the database
should reject it.

Any good system will be a tradeoff. You need to find the benefits of
both approaches, and weigh up to the best of your knowledge of how you
believe the system will be used.

Download DUnit if you haven't already and build test cases, because if
requirements change, you can have confidence your business rules are
still working when you need to pull a slab of logic out of the
database layer.

> 1. Protection of the intellectual property.

This is easier managed in a compiled program.

> 2. Ease of design & maintenance.

This is often easier managed in database stored procedures etc. One
place to fix all workstations.

Adam