Hi all,
Rong Chen wrote:
> Mikael Nystr?m wrote:
>> Rong Chen wrote:
>>>
>>> Do you have any specific need for queries? If you don't need to query
>>> the internals of the objects (or tree of them), it will be quite
>>> simple to just serialize the whole object.
>>
>> I agree with Rong that in simple cases is it enough with serialized
objects.
>> (But I must say that the alternative with applications like "real time
>> data driven decision support systems" is much more scientifically
>> interesting and fun. Otherwise we probably not use the full potential
>> of openEHR.)
>
> This could be achieved by querying in-memory objects, why it has to be
done
> in the persistence layer? Maybe you can give some example, Mikael.
A data driven real time system (in this example a decision support system)
relies heavily on fast and full access to the data. The systems often works
with rules like ?if parameter A and parameter B is < C then check if
parameter D1, D2, D3, D4, D5 and D6 is > 10 and in that case trigger rules
R1, R2, R3, R4, R5, R6 and R7?.
Of cause it is possible to implement data driven systems completely in Java
and only relies on a database management system to store serialized data
objects in BLOBs. For every parameter the system needs to check the system
then needs to take the path to the object which contain the parameter the
system needs, ask the database management system to retrieve the serialized
Java object from its BLOB-storage in the database, deserialize the object to
a readable form, store the object it in the computer memory, read the
parameter you need from the object, invalidate your newly created object and
not get back the memory used for the object until the garbage collector run
it?s next turn. But this strategy needs large resources to run.
If the parameters are stored in direct readable form in the database
management system it is possible for the application to just ask for the
single data it needs and haven?t the need to spend time on deserializing of
BLOBs into readable objects, store large object instead of just the needed
parameter in the computer?s memory and the need for large object to be
garbage collected.
An even more efficient alternative is to implement the rules directly in the
database management system as triggers. Then the rules are applied by the
database management system in the same native way as the data are handled in
the database management system. But this alternative is only possible when
the database management system is able to read the single data values and
not, as in the serialized objects alternative, know that the single data
values are inside a BLOB.
If we are talking about small data driven systems can I accept the ?pure
Java guy?s alternative? and do most of the processing in Java. But if we
would like to have large data driven systems this alternative is needs in
most cases to large resources to work, and we then need to use the ?database
engineer?s alternatives? instead.
> A generic, full-featured query service is tricky enough to do, so why
> not separate the persistence concern from query related logic.
I can accept that it is trickier to implement a good persistence layer
without any serialized objects, but it is definitely not rocket science to
do it. So why not try, so we are able to use the data in more effective
ways?
> Well, I would prefer to see a generic, all-purpose persistence layer,
defined
> by clear interface. Of course, the characteristics will be different
> depending which implementation is actually used. Applications should be
> probably built on top of EHR services, which are also generic,
all-purposed.
> So I wouldn't agree that the persistence layer should be very much defined
> by any particular application. These two, application and persistence,
> should be rather decoupled, and the services layer will be in between.
I agree that we need one well defined independent and good persistence layer
interface. We therefore need to design the persistence layer interface for
the most demanding applications.
Greetings,
Mikael
