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
