dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 9 January 2011 20:12, Ola Hodne Titlestad <olati@xxxxxxxxxx> wrote:
> On 9 January 2011 19:45, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>>
>> Hi Ola
>>
>> Quick question:
>>
>> the resource table _dataelementgroupsetstructure lists all
>> dataelementnames.  Similarly with _indicatorgroupsetstructure,
>> _orgunitstructure and _orgunitgroupsetstructure.
>>
>> In the pivot views you are familiar with, should it be necessary to
>> also have access to dataelement, indicator and orgunit tables or are
>> the resource tables sufficient?
>>
>>
>> If not, could/should we make it so?  eg to bring shortnames into these
>> tables if they are used.  Or, if it is desirable to be able to use the
>> "source" tables, to remove the names from the resource tables?
>>
>
> It would be enough to get the names either from the source or from the
> resource tables yes, no need to have them both places.
> At least I can't see any reason for duplicating these names.
> You know better what is the most efficient way to set this up.
> One related comment:
> The way I have set up the pivot views (you have them) joining the source
> tables (data element, indicator, orgunit) with the above mentioned resource
> tables (using the IDs) only the names present in the resource tables are
> coming through to the pivot table, e.g. an indicator without any
> groups/groups sets or an indicator added after the last refresh of the
> resource table are not coming through in the pivot view. This might be too
> restrictive. Still we should enforce grouping all elements in at least one
> group set for easier browsing both in the DHIS UI and in pivots etc.

Yes this is what is behind my question.  I saw from your queries that
you are using names from the resource tables.  That is ok.  We can do
that with recreated resource tables off site as well.  I'm trying to
understand if we want to or not.  It could certainly be more efficient
to have the resource tables simply add the minimum requirement to make
querying easier (ie making explict the categoryoptioncombos and the
orgunit tree in an sql-friendly way).  But efficiency isn't
everything.  Its also desirable that queries that work in one context
also work in another.

I can go ahead and implement in what I think is the most efficient way
possible - dropping redundancies from the resource tables.  But this
will mean modifying some of those queries (slightly).

Cheers
Bob

> Ola
> -------
>
>>
>> Regards
>> Bob
>
>