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

[Tim Churches]

Ian Haywood wrote:
> 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.

Yes. The target "market" of GNUmed is general prcatices and small
clinics, I thought. They will not be running multiple database servers.
If they do want to source data from other sources, it will not be by
connection to an SQL database, it will be via a Web service (most likely
 SOAP in the real world, or HL7 v2.x wrapped in ebXML), in which case
the results would be stored or at least cached in the practice's local
database. So what is the point of distributed *database* capability.
Certainly the ability to source data from distributed services is
important, but not from distributed SQL databases. And if it slows
everything down...

Tim C

> 
> 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)
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel