mlq97 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.
>
> Is it better to put maximum "intelligence" into the DB in the form of
> referential rules, sql procedures and triggers etc, or should this be
> mainly in the (Delphi)front end?
>
> I'm concerned about:
>
> 1. Protection of the intellectual property.
> 2. Ease of design & maintenance.
>
> Thanks in advance for any guidance.
>

My systems is used by a limited number of clients, each have their own
tweaks and specialties. Each client has 10-50 users. I need to be able
to change some logic anytime and as fast as possible. For me it's a huge
boon to be able to have *all* the business logics in the DB. I just
change a trigger or a procedure. I have ended up with the *exact* same
front end for all my customers.

This is of lesser concern to you in your case. IMHO considering
protection of intellectual property this is the main drawback for you.
Triggers and procedures can not be sufficiently "protected". There is an
article somewhere on the an FB dedicated webpage.

Another drawback would be that interaction between the client and the
server need to be more intense the faster a "rule" is to be exposed to
the user. The transaction logic is very usable though to "simulate" a
(popularly called) desktop application. It seems this is not something
that you'll have to worry about in your environment. This is something
to keep in mind when connecting to FB over DSL or modem.

You say that you app will be used in a multiuser environment. Well, in
my opinion; triggers and procedures combined with well tuned transaction
handling is absolutely unmatched where integrity and ease of coding is
concerned. Imagine any batch-like job that involves update of more than
one record. These updates should only be done if all updates succeed. To
do this on the client would often lead to very convoluted coding, extra
checks and code to "roll back" when there is an error in the middle.
With transaction handling everything is automagically rolled back
without need for special code, inside multiuser and everything else.

Concerning maintenance an SQL script is very efficient in my experience.
If the script works once it *usually* will work on another DB with the
same metadata and different content. Just make sure theres only one user
logged on that runs the script. There are some tools out there that
produces the script for changing database x into looking like database
y. These work very well.

HTH, /Dany