dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 7 December 2010 10:08, Ola Hodne Titlestad <olati@xxxxxxxxxx> wrote:
> On 7 December 2010 09:02, Knut Staring <knutst@xxxxxxxxx> wrote:
>>
>> 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.
>>
>
> I have previously been very defensive of the "must add up to a total" rule,
> but over the last months I have changed my mind here.
> There are some use cases, and we keep seeing more and more of these,
> especially with stock,

Out of curiosity, how much of this is with stock?

>where you will quickly end up with 500+ data elements
> in a flat data element model for just one form, which might be more than all
> the other data elements together. Your list of data elements will get
> polluted, all browsing that involves data elements will be more difficult.
> And of course being able to automatically get that nice tabular form is a
> major bonus, although I tend to think of the very long data element lists as
> a worse effect of this than the extra one-off work of designing the form.
> I have discussed this with Lars in the past and I think many of us agree
> that the current use of the model is not ideal, we should not tie the model
> this closely to the presentation layer and we have said before on this list
> that we should look at a better data entry form model in the future. But
> this will take time and is not realistic to get in place for another 6
> months at least.
> While waiting for a better model I agree with Knut that we can use the
> categories to reduce the number of data elements and to get the
> auto-generated form even though the options don't add up to a meaningful
> total. Of course then we must make sure that this total is never used in a
> report, validation rule, or indicator expression etc. One way to do this is
> to add a property on the category that says "non-aggregatable" or similar,
> to indicate that we never want to use the aggregated total. This way we can
> filter away the totals in indicator formula editors etc. (Lars implemented
> the use of totals there yesterday).
> Pivot tables is another issue I guess, since we cannot control the
> aggregation in the same way, since the users can zoom in and out as they
> want. But if we always provide the catoptioncombo field in the pivot tables,
> as we do today, the users will easily see, if they want, the raw data below
> the total. There are other dimensions in the pivot table that are not
> aggregatable (I think Lars googled this word and found it to be existing..),
> like DataElement and Indicator, and the totals for these do not make sense
> either. Of course the pivots will be a lot better and easier to use when the
> totals for data elements actually are useful, so that we don't have to show
> all the options all the time. We can create filters so that stock data (or
> non-aggregatable data) is not part of the core pivot tables and create
> separate special tables for these, or just trust that the users will do this
> filtering themselves, and understand what the totals mean and not mean.
>
> Ola
> ---------
>
>>
>> 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
>
>
> _______________________________________________
> 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
>
>