Re: [Gnumed-devel] Re: Document for introducing GnuMed (regarding India's project opportunity)

[Ian Haywood]

Karsten Hilbert wrote:

> It would be possible to use distributed databases to
> physically separate services even now. That would mean we
> would have to use the dblink module that is in the contrib/
> part of PostgreSQL and not in the core distribution.
Why?
We scrupulously avoid query joins across services precisely so
they can be in separate physical hosts. dblink, purposefully but IMHO
pointlessly, is avoided.

What I'm saying is gnumed has incurred so much complexity for such a rare 
feature.
I note its original advocate, Horst, has wisely returned to a monolithic 
database
for gnumed-mini.

Indeed, it is this rule which led us to the "dumb-backend, smart-client" design
(because only the client can unite data from the myriad services), which I find
increasingly clumsy

Perhaps we should reconsider requiring distribution, those few who want 
distributed databases [1]
can use dblink () and suffer the speed penalty currently enjoyed by everyone.

> Hence: As long as we don't specify and use a "good" PUPIC I
> will not enable distributing data across separate databases.
Indeed, we shouldn't over-complicate development for the sake of a feature we 
can't
safely offer anyway.

Ian

[1] I am referring to functional distribution (table X in server Y), not 
tablespaces
(table X on disk Y in the one host) nor whole-database replication, either of 
which
may fulfill the needs of at least some who may have believed they needed 
distributed databases.
(when we last debated this, neither existed for postgres)

signature.asc
Description: OpenPGP digital signature