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 > [email protected] > http://lists.gnu.org/mailman/listinfo/gnumed-devel _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
