This has got me thinking once again what a category/combo/option actually is and how the current implementation makes too many assumptions, like that categories should add up to a total.
I would suggest we continue thinking about it in background document I created a while back.. https://docs.google.com/document/d/1swOxM-E-bYRBXhnalvAtuMb8FGYocxOCVvJS36B25C4/edit?hl=en On Tue, Dec 7, 2010 at 1:02 PM, Knut Staring <[email protected]> wrote: > On Tue, Dec 7, 2010 at 2:55 AM, Thuy Nguyen <[email protected]> > wrote: >> Dear Johan, >> Thank you for your suggestions. Please scroll down to see my mail >> >> >> >> On Tue, Dec 7, 2010 at 1:59 AM, <[email protected]> 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 > > _______________________________________________ > Mailing list: https://launchpad.net/~dhis2-devs > Post to : [email protected] > Unsubscribe : https://launchpad.net/~dhis2-devs > More help : https://help.launchpad.net/ListHelp > -- Jason P. Pickering email: [email protected] tel:+260968395190 _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
