| Subject | Re: [firebird-support] Best place for rules: Front end or DB? |
|---|---|
| Author | The Wogster |
| Post date | 2006-02-22T11:54:57Z |
mlq97 wrote:
referential rules, belong in the database, triggers belong in the
database, procedures, well some can be, some can not be.
The reason I say this, is that databases can be used for other purposes,
a customer who wants access to his/her data, should have it. Making
sure that another application must abide by those same rules, makes the
data more robust.
Is there a chance in the future that other front ends might be needed,
say a web front end or a Unix front end? If so, then you want as much
logic in the database as possible to make those front ends easier to build.
it's better to lose a little on the IP side, and not get those Sunday
morning phone calls from a customer with a corrupted database that needs
to be functional by Monday morning, because he goofed up something using
Excel to access HIS data that violated the business rules.
it's easier to customize a rule in an uncompiled database, then in an
executable that requires recompiling and redistribution.
> What is the perceived wisdom about where to put business rules for aData protection should be in the database, that is things like
> 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?
>
referential rules, belong in the database, triggers belong in the
database, procedures, well some can be, some can not be.
The reason I say this, is that databases can be used for other purposes,
a customer who wants access to his/her data, should have it. Making
sure that another application must abide by those same rules, makes the
data more robust.
Is there a chance in the future that other front ends might be needed,
say a web front end or a Unix front end? If so, then you want as much
logic in the database as possible to make those front ends easier to build.
> I'm concerned about:This is probably less of an issue, then most people think. Sometimes
>
> 1. Protection of the intellectual property.
it's better to lose a little on the IP side, and not get those Sunday
morning phone calls from a customer with a corrupted database that needs
to be functional by Monday morning, because he goofed up something using
Excel to access HIS data that violated the business rules.
> 2. Ease of design & maintenance.Business rules can be different customer to customer at some points, and
it's easier to customize a rule in an uncompiled database, then in an
executable that requires recompiling and redistribution.
>
> Thanks in advance for any guidance.
>
>
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://firebird.sourceforge.net and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>