Re: Implementing "thick"/"fat" databases

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