Postgres Professional
en

Re: Implementing "thick"/"fat" databases

От: Gavin Flower
Тема: Re: Implementing "thick"/"fat" databases
Дата: ,
Msg-id: 4E2BE427.8090906@archidevsys.co.nz
(см: обсуждение, исходный текст)
Ответ на: Re: Implementing "thick"/"fat" databases  (Chris Travers)
Список: pgsql-general

Скрыть дерево обсуждения

Implementing "thick"/"fat" databases  ("Karl Nack", )
 Re: Implementing "thick"/"fat" databases  (Darren Duncan, )
  Re: Implementing "thick"/"fat" databases  (John R Pierce, )
   Re: Implementing "thick"/"fat" databases  (Darren Duncan, )
   Re: Implementing "thick"/"fat" databases  (Gavin Flower, )
    Re: Implementing "thick"/"fat" databases  (Chris Travers, )
     Re: Implementing "thick"/"fat" databases  (Gavin Flower, )
     Re: Implementing "thick"/"fat" databases  (Merlin Moncure, )
      Re: Implementing "thick"/"fat" databases  (Chris Travers, )
       Re: Implementing "thick"/"fat" databases  (Merlin Moncure, )
        Re: Implementing "thick"/"fat" databases  (Vincent Veyron, )
  Re: Implementing "thick"/"fat" databases  ("Karl Nack", )
 Re: Implementing "thick"/"fat" databases  (Alban Hertroys, )
  Re: Implementing "thick"/"fat" databases  ("Karl Nack", )
 Re: Implementing "thick"/"fat" databases  (Chris Travers, )
  Re: Implementing "thick"/"fat" databases  (David Johnston, )
   Re: Implementing "thick"/"fat" databases  ("Karl Nack", )
  Re: Implementing "thick"/"fat" databases  (David Johnston, )
   Re: Implementing "thick"/"fat" databases  (Chris Travers, )
  Re: Implementing "thick"/"fat" databases  ("Karl Nack", )
   Re: Implementing "thick"/"fat" databases  ("Karsten Hilbert", )
    Re: Implementing "thick"/"fat" databases  (Chris Travers, )
 Re: Implementing "thick"/"fat" databases  (Darren Duncan, )
  Re: Implementing "thick"/"fat" databases  (David Johnston, )
 Re: Implementing "thick"/"fat" databases  (Chris Travers, )
  Re: Implementing "thick"/"fat" databases  (Chris Travers, )
  Re: Implementing "thick"/"fat" databases  ("Karl Nack", )
 Re: Implementing "thick"/"fat" databases  (Sim Zacks, )
  Re: Implementing "thick"/"fat" databases  (Chris Travers, )
   Re: Implementing "thick"/"fat" databases  (Sim Zacks, )
    Re: Implementing "thick"/"fat" databases  (Chris Travers, )
     Re: Implementing "thick"/"fat" databases  (Sim Zacks, )
      Re: Implementing "thick"/"fat" databases  (Chris Travers, )
 Re: Implementing "thick"/"fat" databases  (Frank Lanitz, )
  Re: Implementing "thick"/"fat" databases  (Pavel Stehule, )
   Re: Implementing "thick"/"fat" databases  (Frank Lanitz, )
  Re: Implementing "thick"/"fat" databases  (Sim Zacks, )
   Re: Implementing "thick"/"fat" databases  (Frank Lanitz, )
   Re: Implementing "thick"/"fat" databases  (Chris Travers, )
 Re: Implementing "thick"/"fat" databases  (Chris Travers, )
  Re: Implementing "thick"/"fat" databases  (Merlin Moncure, )
   Re: Implementing "thick"/"fat" databases  (Chris Travers, )
    Re: Implementing "thick"/"fat" databases  ("Karsten Hilbert", )
     Re: Implementing "thick"/"fat" databases  (Peter Bex, )
    Re: Implementing "thick"/"fat" databases  ("Karl Nack", )
  Re: Implementing "thick"/"fat" databases  ("Karl Nack", )
   Re: Implementing "thick"/"fat" databases  (Sim Zacks, ) 
On 24/07/11 17:51, Chris Travers wrote:
>> 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.
> In general, I am not convinced that middleware is inherently more
> maintainable than in-db procedures.
>
> But the fundamental question is:  Is this a a one-application
> database?  If it is, you can use the middleware to be that application
> lock the db down so only the middleware can use it etc.
>
> But what if it isn't?    What if we want to support a variety of
> applications against the same relational database?  This has to be
> fairly commonplace.....
>
> In this way my experience is that it is often helpful to maintain
> several levels of stable, public API's both on a table level if
> possible (as attachment points for triggers), stored proc API's for
> actually inserting data into relevant areas while enforcing
> appropriate business logic, and so forth.
>
> One of the things we are doing in LedgerSMB is to make the stored
> procedures discoverable, so the argument names (and eventually the
> return types) will have meaning the application can use in building
> calls for the procedure.  This eases one important maintenance point
> because arguments are automatically picked up by the application and
> as long as best practices in coding are followed, will be handled
> sanely.  (The interface will be extended in the future so that return
> types determine the class, and the arguments in determine whether we
> are talking about a presumed object property or a presumed
> application-specified argument.)  Theoretically, we should be able to
> build objects in languages picking up methods and properties from the
> Pg system catalogs but we haven't gotten that far yet with code
> generation.
>
> Best Wishes,
> Chris Travers
So it really boils down to 'It depends...'  :-)

I first started designing systems over 30 years ago.  I remember my
first design principle I came up with, but more importantly that my next
project ignored it for good reasons (same mainframe COBOL environment in
both cases)!

I feel that for a large company, then the middleware approach is
probably better when you have many diverse applications that share a lot
in common, but it depends on many different factors.

В списке pgsql-general по дате сообщения:

Предыдущее:
От: Yan Chunlu
Дата:
Сообщение: Re: streaming replication does not work across datacenter with 20ms latency?
Следующее:
От: Adrian Klaver
Дата:
Сообщение: Re: weird table sizes