Quoting Richard Hosking <[EMAIL PROTECTED]>: > Thanks Sam > > Gnumed is using PostgreSQL as a backend with an intelligent middleware > "broker" actually it's pretty dumb. IMHO bad design of the middleware is what's been slowing us down, which is why these discussions on a new backend are avoiding the actual problem and so slightly frustrating (but interesting all the same)
> between client and DB which can be remote. no it can't. > The OpenEHR reference model and Archetypes could provide a rational data > model and DB schema. How much work would be involved in converting these > to SQL? Probably quite a lot. > I guess the simplest method would be to do it by hand for a set of > archtypes/structures that are sufficient for your record. Yes, however this has no compelling advantages over the current gnumed backend: why do the work again to end up in the same place? > It seems > overkill to write a program that will only need to do it once - or is > there a need for dynamic/runtime data objects - if so why? Yes, there is. The idea is to specify the data structure once, and then have the system autogenerate the middleware and backend code. Otherwise you end up with the current gnumed situation: having to write a datastructure in SQL, and then do it all again in Python (or whatever middlware language) There are 3 ways: 1- specify in Python (i.e. the middle layer) and generate backend SQL 2- specify in SQL and generate middleware 3- specify in a third language which then is translated into SQL and also runs the middleware. I'm not suire if OpenEHR is a 1 or a 3. Ian _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
