Re: Application Design and PostgreSQL - Mailing list pgsql-general

Bruno Wolff III wrote:
>
> I think having the business rules in the applications is a good way to
> lock your customers into your tools. Unless you provide good and current
> documentation about the business rules, writing local tools to update
> the database is difficult to do with any confidence.
>
> If the integrity checking is in the database, the constaints document
> the business rules and will keep broken programs from updating the database
> in a way that breaks the assumptions made by the applications programs
> that are written in the database.
>
> I find dealing with PeopleSoft and Magic helpdesk databases frustrating,
> because it isn't easy to get the rules used by their applications. We
> either have to use their crappy labor intensive interfaces for entering
> data or try to figure out what the rules are and hope we get things
> right writing scripts for simplifying administration.

I've personally found that open source tools provide the best solution,
and prefer the mod_perl, Apache, and DBI solution. They're free, provide
no vendor lockin, and have been around for a while [they have legs], and
outside the web sphere, you can quickly utilize the perl/DBI solution
for just about anything pulling data from a database, not to mention
interfacing with email servers, encryption, and the hundreds of other
modules freely available from cpan.

Since we specialized in moving data from any database to the desktop via
a browser client, we first used ColdFusion. This closed solution was not
as flexible as our open source choice, but it allowed us to "get our
feet wet" using a standard tool with wide programmer support available.

Integrity checking in a database is necessary, but attempting to
construct an application with triggers & stored procedures will lock you
into a particular database, or at the very least, make it very costly
and time consuming to move to a different platform tomorrow... This
approach also isn't very productive if you're charged with developing
applications that need to extract data from Sybase, DB2, Oracle and MS
SQL server databases, but if you're just using one database you can
pretty much do what you want.

Many large companies, and consulting groups serving the needs of many
large & small companies need to develop flexible solutions to the myriad
of databases their clients have chosen to use. Implementing the logic of
your applications in the middleware enables you to develop an
application that will work with virtually any database that has a
standard ODBC, JDBC, DBI, etc... driver, and the components you develop
for one client are usually portable to satisfy another clients
requirements. All this is lost if you try to develop all the triggers &
stored procedures needed to mimic an application through a database's
internal structure.

Agile solutions are better implemented through middleware...

[Also, I remember having a consulting company charge us $180.00 per hour
for an Oracle DBA, but I can get a perl programmer for $70.00 an hour.
Do the math... Not only is a middleware solution more flexible, but it's
also less expensive...]