gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Re: Document for introducing GnuMed (regarding India'


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Re: Document for introducing GnuMed (regarding India's project opportunity)
Date: Sun, 20 Mar 2005 16:23:03 +0100
User-agent: Mutt/1.3.22.1i

On Sun, Mar 20, 2005 at 11:00:38PM +1100, Ian Haywood 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?
Because there is no other way of accessing tables
across databases ?

> We scrupulously avoid query joins across services precisely so
> they can be in separate physical hosts.
No. We avoid them because they will not work without dblink.
dblink works for separate databases no matter on which host
each one is on.

> dblink, purposefully but IMHO pointlessly, is avoided.
Well.

> What I'm saying is gnumed has incurred so much complexity for such a rare 
> feature.
Is it really that much complexity ?

> I note its original advocate, Horst, has wisely returned to a monolithic 
> database for gnumed-mini.
Out of lack of time and a must to work with the commercial
EMR, I should think.

> 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
Not sure I can follow. Our backend IS fairly smart ?

> 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.
Speed penalty ? And how would they use dblink lest it be
integrated right from the beginning ?

> >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.
Oh, I believe we CAN offer it in a good enough way. And we'll
actually really want a PUPIC no matter the distribution state
of the database.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

[Prev in Thread] Current Thread [Next in Thread]