alternatives to datbase dependence
On Tue, 12 Nov 2002, Horst Herb wrote:
> On Tue, 12 Nov 2002 08:25, Andrew Ho wrote:
> > Notify and listen are not standard SQL (e.g. SQL92). Therefore, I think
> > it is a terrible idea to use it - if you care about using GnuMed with a
> > different database backend.
> We can't use a different database backend anyway, sinc we heavily depend on
> stored procedures for all sorts of triggers, which is not portable.
Horst,
I see. PostgreSQL is a good choice if you have to depend on one database
backend. However, I don't think that is the only way to go.
> Notify and listen is an absolutely *essential* feature for a complex database
> accessed and modified by many users simultaneously. How else would a client
> get to know that the record he is displaying right now just has been modified
> by another client?
There are different ways to detect, generate, and deliver messages in
*real time* - depending on the client-side technology available. The
decision that we are speaking of is whether to code the server-side of
this "notification service" in the application/middleware layer or
database backend.
My preference is to do this (and stored procedures/triggers too :-) in the
application/middleware layer - just to achieve portability across
database backends!
> Think of a "waiting room" widget on the doctor's interface. The receptionist
> pops a patient who has just arrived onto the "waiting list" table, and now
> the doctor's screen has to reflect it. How would you do it without
> notify/listen?
How about instant messaging? :-)
> Poll in regular intervals?
Maybe. Certain intermittently connected clients may need to poll in
regular intervals.
The point is, do you really have to hard-code this into the database?
How are would it be for GnuMed to support intermittently connected
clients?
> That would generate a huge unneccessary backend traffic and would make
> programming the client a lot more complicated, since there are
> virtually *hundreds* of tables where such asynchronous backend
> communication is needed.
I don't know how you setup the database schema that you are triggering
hundreds of database table "communications" routinely. Maybe there is a
better way to do it?
My preference is to minimize the number of tables changed per transaction.
Makes for easier debugging too!
Sorry if I am expressing biases that come from differences in goals of the
OIO project vs. the GnuMed. I just want to share some of the thinking that
led me away from implementing code that ties me too closely to any
particular platform. (At one point, I even drew up plans to implement OIO
on Java :-).
Best regards,
Andrew
---
Andrew P. Ho, M.D.
OIO: Open Infrastructure for Outcomes
www.TxOutcome.Org
Reply to: