Re: 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
downthe 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. 
>