On 9 January 2011 20:12, Ola Hodne Titlestad <[email protected]> wrote: > On 9 January 2011 19:45, Bob Jolliffe <[email protected]> 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 > > _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
