Re: [Gnumed-devel] database abstraction

[Karsten Hilbert]

> You can have it two ways:
Actually it dawned on me during night shift that I do can
have it both ways without either/or even as I will explain
below.

> - either you limit yourself beforehand to a few known situations, then 
> the highest level of abstraction as you propose makes sense
> OR
> - the interface is fairly ignorant regarding available data, but it can 
> handle whatever data is available and the interpretation is left to the 
> user by default unless specific business logic is implemented on top of 
> the rather low level "ignorant" data
                        ^^^^^^^^
This is the keyword.

IF we are trying to implement a "semantically ignorant"
lowest level on top of which arbitrarily complex business
objects can be built I am all for it.

a) KISS is still en vogue.
b) As little overhead as practical is still en vogue.
c) Thin layers are still en vogue.
d) Stored procedures are still en vogue.
e) Kylie Minogue is still en vogue (sorry, couldn't resist).

As soon as I get the time I will investigate how to use
Python as a server side scripting language. Which should make
the code portable even between stored procedures and Python
clients. Now that would be something :-)

BTW the beauty of Hilmar's design is that it is data driven.
I.E. it is configurable via a text file without need to hack
the code itself.

Hope that clarifies things a bit.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346