Hello Dieter, Wednesday, June 28, 2000, 3:57:56 AM, you wrote: DM> If your patient data is in an SQL database, you do not need DM> to build (redundant) ZClass instances for them. DM> Instead, you would use Z SQL Methods to access them. As i realize, ZSQL methods are merely SQL statements for data manipulation - select, insert, delete and so on. But some application logic and data integrity rules may be IMHO wrapped into ZClasses instead of triggers and stored procedures. It looks promising for instance to have base class Patient (with appropriate ZSQL methods), which can produce other classes like Patient with knee problems, Patient for total arthroplasty and so on, where properties of base class including ZSQL are inherited and require minimal additions/changes. Do i suppose wrong? Best regards, Alexander N. Chelnokov Ural Scientific Institute of Traumatology and Orthopaedics str.Bankovsky, 7. Ekaterinburg 620014 Russia E-mail: uniitos@mail.utnet.ru, alex_chel@hotmail.com ICQ: 25640913
On Wed, 28 Jun 2000, Alexander Chelnokov wrote:
As i realize, ZSQL methods are merely SQL statements for data manipulation - select, insert, delete and so on. But some application logic and data integrity rules may be IMHO wrapped into ZClasses instead of triggers and stored procedures. It looks promising for
I think what you are looking for here is the concept called "pluggable brains". As I understand it (never having used it myself), it allows you to wrap the returned results up as instances of a python class, thus supplying object logic to your rdbms data. Whether or not ZClasses can play the role of pluggable brains I don't know, but I have a feeling they would be overkill for that. --RDM
participants (2)
-
Alexander Chelnokov -
R. David Murray