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

I don't agree with the philsophy.

A better approach would be put the code in the back end when you can, else
fluff it into middleware. Your approach may seem the most flexible however
my experience make me believe that the reverse is true. The company that I
use to work for had two applications one which used server side logic on
oracle the other was a middleware solution that could float on a number of
different DBs. Three transitions were
The Oracle product was ported to informix.     Easy
The Oracle/Informix product was web enabled     Easy
The Middleware product was web enabled        Initially appeared easy but
was very difficult and had many teething problems.
Middleware tends to bloat quickly and hits exceptions get pulled into body
of the code. I believe that IBM's DB2 adopted a somewhat similiar
architecture to postgresql because they found that middleware was slower and
less flexable.


--
Ian Willis

-----Original Message-----
From: Buddy Lee Haystack [mailto:haystack@email.rentzone.org]
Sent: Thursday, 19 July 2001 1:39 AM
To: Ian Harding
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Application Design and PostgreSQL


Different problems require different solutions. I try not to drive a
thumbtack with a sledgehammer - usually. ;)

I provided a personal experience because the solution you select will be
dependent upon on the specific project & client requirements.

More personal experience:

I found that many of our internal clients were using different
databases. Some clients had DBA's to administer their Oracle database
farms, while other clients had a computer literate individual to watch
over their Microsoft Access Database. The level of experience, and
breadth of knowledge varied considerably from client to client.

By implementing the business logic within the application layer, we were
able to create applications that easily worked with the client's
preferred database. Additionally, we were most often involved in
creating applications that extracted data from a database owned &
operated by individuals & groups beyond our control & influence. Some
DBA's would only allow others to access their databases using stored
procedures, while other departments and groups allowed dynamic SQL to be
used.

Considering the easy availability of a considerable number of data
storage solutions available around the globe, we decided to incorporate
our business logic within the application layer. This helped us create
some standardized application components that we were able to REUSE for
a number clients. We were not forced to constantly retool when a new
client surfaced, or an established client decided to switch to a
different data storage solution.

Middleware makes this agility possible, and I believe that it should be
the preferred solution to help keep pace with information technologies
rapid change. We've had quite a number of clients switch from using MS
Access to more scalable solutions, and few of them foresaw the need at
the time they chose MS Access... If only they had the foresight to have
chosen PostgreSQL to begin with. :)


Ian Harding wrote:
>
> If you start with PostgreSQL, you can put your logic in the database, as
you will prevent any requirement to migrate down the road! <BSEG>  This from
someone who is currently migrating stored procedures and triggers from SQL
Server to PostgreSQL...  However, I don't have to change my front end app
(AOLServer) much at all.
>

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html