dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Final thought from me for now ...

On 14 September 2011 17:11, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
> On 14 September 2011 15:32, Carl Leitner <litlfred@xxxxxxxxxxx> wrote:
>> Hi All,
>>  I was just watching this thread and wanted to share our possibly similar
>> experiences from iHRIS.  Admittedly I have not looked at the details of how
>> DHIS is implementing dynamic attributes in the database,  but I would
>> suspect the design pattern is similar to how iHRIS has done its form and
>> fields.  (I have also seen this design pattern in openMRS).
>>
>> Although this flexibility has been great, it did have a significant impact
>> when it came to reporting time.    Even with proper indices, MySQL couldn't
>> handle multiple joins and the reports quickly became essentially unusable.
>> As a solution we had to implement a middle layer (form caching) which sits
>> between the data storage system and the reporting system.

There are some places where we do something similar.  Most notably the
DHIS resource tables can be thought of as something like this
specifically for reporting.

>We were able to
>> do this only only after addaing a sufficient amount of meta-data about our
>> fields and forms (e.g. the relationship between them, the SQL data types,
>> etc.)
>>
>> I don't know how heavily you plan to make use of the dynamic attributes in
>> reporting, so it may be a non-issue for you all, but it may be a topic for
>> your design call.
>
> Hi Carl
>
> Thanks for the observation.  I am also not sure to what extent these
> will be used in reporting - though I can only imagine they will be
> used for something :-)
>
> Reducing to the extreme we would simply have an identifier, the class
> of the object and its attributes.  And from an external perspective
> this is a neat and orthogonal way of viewing them.  I even recall
> Murod has done something fairly similar.  But as you point out, this
> neat reductionism can come back to bite on the performance side.  So
> what is more likely to emerge as a pragmatic extension which builds on
> the history of what is already there, is a hybrid of "core" attributes
> and "dynamic" ones.  The core attributes being hard coded columns in
> tables and the dynamic ones being linked through database relations.
> Which gives rise to the question of which should be core and which
> should be dynamic and why.  At first pass the answer to that is
> probably straightforward - the core attributes already exist as column
> names, and are already heavily used in reporting.  In time we might
> find a more rational basis to distinguish.
>
> From an external exchange perspective (I'm trying to make my life
> really simple) there is a level at which these are all simply
> attributes.  Whether a particular system, such as dhis, strategically,
> historically or accidentally chooses to represent some of these as
> database fields and some of them as dynamic attributes is an internal
> detail to that system.  So when I see an orgunit I might see something
> like:
>
> <orgunit identifier(s)=".. ".
>   type="Clinic"
>   name='Bob's Clinic'
>   alternateName='Robert's Fancy Clinic for the bewildered'
>   geoCode="..."
>   contactPerson='Bob Jolliffe'
>   bedcapacity=0  etc />
>
> It is up to the consumer of such an element to decide how to actually
> store this stuff internally and different systems might well do it
> differently.  In DHIS I guess we would collect up all the fixed fields
> we have and store them, then take whatever is left and store them as
> dynamic or extended attributes.  From the producer side we want to be
> able to identify the object and then dump all its attributes -
> implementing from DHIS perspective would imply simply dumping all the
> core attributes followed by whatever dynamic attributes it might have,
> without necessarily exposing this detail in what gets spat out..
>
> Managing the performance/flexibility tradeoff is tricky.  Particularly
> as we want to combine both the qualities of a performing data
> warehouse and a flexible metadata repository into a single system.  I
> think the hybrid approach will take us so far.  Its good to see Morten
> working on it.
>
> Cheers
> Bob
>
>> Cheers.
>> -carl
>>
>> On 09/14/2011 10:13 AM, Bob Jolliffe wrote:
>>
>> OK.  Lets try Friday morning 09h30 my time - that's 10h30 Oslo time
>>
>> Dial-in number: +1-424-203-8000
>> or Skype call to: freeconferencing.8000
>> Code: 553472
>>
>> I know you are under pressure to finish this stuff so the intent is
>> not to slow things up.  Just keep us all pointing in same direction
>> :-)
>>
>> Cheers
>> Bob
>>
>> On 14 September 2011 14:40, Jo Størset <storset@xxxxxxxxx> wrote:
>>
>> Den 14. sep. 2011 kl. 15.32 skrev Morten Olav Hansen:
>>
>> Can I suggest we fit in a brief design call this week to touch base?
>> I have a freeconference number we can use.  Maybe tomorrow or Friday?
>> Lars are you around and/or available as well?
>>
>> Sure. I can tomorrow or Friday. Lars is in Uganda, but I'm sure he'll
>> respond later if he has time for a conference call.
>>
>> I should also be able to make it.. Just give the time in advance :)
>>
>> Jo
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>