5.5. FAQ

> I would be interested in hearing about the database design > history and the purpose of the distributed database architecture > that you have implemented, (smart, but possibly a little > over-kill I would have thought at first glance).

Horst Herb:The main reason why we had to split the monolithic backend up: - some countries provide centralized demographic information. It would be inefficient and unreliable to try to copy such a centrally well maintained demographic database. We should rather allow to tap into it via distributed services. - some countries provide centralized pharmaceutical information - some countries provide centralized immunisation databases - some conutries centralize certain pathology results etc. Sometimes, this happens on a smaller scale like within a hospital where they already have successfully implemented some of these services, they are running smoothly, and they find no reason to pull it apart again. GNUMed will shine in such an environment because it will be far easier to integrate into such existing solutions than other software. Thus we try to find out which "services" are relatively independent from others, and isolate them into particular "virtual" databases. That way, it will be magnitudes easier to write simple wrappers for external sources and use them. The main obstacle is tha Postgres in itself does not support cross-database queries, and we have to take care of referential integrity between external sources ourselves. Note: we should put in a description on how this is achieved now (client side) vs. how we would want this (either built into postgres or via a dedicated demon on the backend with listen/notify)

Karsten Hilbert: There isn't really much choice: Doing everything in one monolithic database isn't quite flexible enough (distributed practices with a WAN link, remote clinical repository but local drug information data store). The difference between hardcoding 2 or 3 database and doing it the Right Way as we are trying to do now isn't very much of a difference. So there aren't really many steps inbetween "monolithic" and "distributed according to some configuration". Yes, it's a bit more complex but to the client side it shouldn't be any more complex than: dbbrooker.GetConnection('personalia') dbbrooker.GetConnection('BLOBS') If we then properly encapsulate accesses into objects we don't experience too much pain in using the distributed version. It does get a bit more involved with keeping strict referential integrity across databases but Horst can explain the issues better than me.