[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Re: Document for introducing GnuMed (regarding India'
From: |
Ian Haywood |
Subject: |
Re: [Gnumed-devel] Re: Document for introducing GnuMed (regarding India's project opportunity) |
Date: |
Sun, 20 Mar 2005 23:00:38 +1100 |
User-agent: |
Mozilla Thunderbird 0.8 (X11/20041012) |
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