dhis2-devs team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

On Tue, Dec 7, 2010 at 2:55 AM, Thuy Nguyen <thuy.hispvietnam@xxxxxxxxx> wrote:
> Dear Johan,
> Thank you for your suggestions. Please scroll down to see my mail
>
>
>
> On Tue, Dec 7, 2010 at 1:59 AM, <johansa@xxxxxxxxxx> wrote:
>>
>> Dear Thuy,
>>
>> I'm not very familiar with the requirements in Sri Lanka, but I have a few
>> general comments. First, the categories and combinations should be used
>> when we want to aggregate them into a data element that is a natural total
>> of these categories. For stock, this is usually not the case, as we do not
>> want to add start balance, received, issued, and monthly requirement (in
>> this case).
>
> About the total meaning of categories and categories options. I got the
> lesson from my mistake in Vietnam. So I didn't want to repeat again by
> explanation people here. But again because of the instant benefit of
> category data elements such as the defaul entry form will generate
> automatically with good form which DHIS provided. And the shorting of
> creating data elements,... So the person who do this project decided to use
> categories for this report as well as other reports for equipments like
> beds, tables,... I knew it is wrong for the meaning of categories which
> developers in DHIS wish to use. But I don't know serious reason for defense
> on this. That's why I consult you to know what will happen in the future
> when data base become huge if we use category options like this for data
> elements? Is it affecting to retrieving information later?

Hi Thuy,

I personally think one has to weight these things against each other.
I understand very well the desire to have nice autogenerated forms,
and I don't really see the big problem with using categories this way
AS LONG AS one bears in mind that the total will not work. I think the
major downside to doing it like this is that Pivot tables will not
work well on these dataelements, since the whole point of pivot tables
is to easily sum up - and if some of the sums are meaningless, that
restricts the usefulness of the pivot tables.

It would be nice if it were possible to easily generate good looking
forms without violating the semantics of the aggregation model, though
I suppose that would require a decoupling of the form section
generating machinery from the data element model. One would then be
able to assign categorycombos to a section, but also group data
elements in sections external to the disaggregation model.

Knut