Re: Implementing "thick"/"fat" databases

From: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
To: John R Pierce <pierce(at)hogranch(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Implementing "thick"/"fat" databases
Date: 2011-07-23 09:01:41
Message-ID: 4E2A8DF5.9050809@archidevsys.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 23/07/11 12:05, John R Pierce wrote:
> On 07/22/11 4:11 PM, Darren Duncan wrote:
>> Karl Nack wrote:
>>> I've been following a few blogs
>>> (http://database-programmer.blogspot.com/,
>>> http://thehelsinkideclaration.blogspot.com/) that make a very
>>> compelling
>>> argument, in my opinion, to move as much business/transactional
>>> logic as
>>> possible into the database, so that client applications become little
>>> more than moving data into and out of the database using a well-defined
>>> API, most commonly (but not necessarily) through the use of stored
>>> procedures.
>>
>> I strongly agree with that design philosophy. One principle is that
>> the buck stops with the database and that regardless of what the
>> application does, any business logic should be enforced by the
>> database itself. Another principle is to treat the database like a
>> code library, where the tables are its internal variables and its
>> public API is stored procedures. Using stored procedures means you
>> can interact with the database from your application in the same way
>> your application interacts with itself, meaning with parameterized
>> routine calls.
>
> the alternative 'modern' architecture is to implement the business
> logic in a webservices engine that sits in front of the database, and
> only use stored procedures for things that get significant performance
> boost where that is needed to meet your performance goals.. Only this
> business logic is allowed to directly query the operational database.
> The business logic in this middle tier still relies on the database
> server for data integrity and such. The presentation layer is
> implemented either in a conventional client application or in a
> webserver (not to be confused with the webservices).... so you have
> user -> browser -> webserver/presentation layer ->
> webservices/business logic -> database
>
> The main rationale for this sort of design pattern is that large
> complex business logic implemented in SQL stored procedures can be
> rather difficult to develop and maintain
>
I was thinking similar thoughts, but you not only beat me to it, you
made some good points I had not thought of!

The only thing I can think of adding: is that it would be good to lock
down the database so that only the middleware can access it, everything
else accesses the database via the middleware.

Cheers,
Gavin

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alban Hertroys 2011-07-23 10:01:42 Re: Implementing "thick"/"fat" databases
Previous Message Alban Hertroys 2011-07-23 08:59:15 Re: Update columns in same table from update trigger?