dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

>
> It seems to me that adding a PeriodType to the DataElement is
> definitely redundant.
>
> DataElement should always be a member of at least one DataSet - and
> there is already be an (implicit) constraint that DataElements of a
> DataSet will be of the same PeriodType.


>
> What is probably required (if it doesn't yet exist) is an application
> enforced constraint that a DataElement can only be a member of
> different DataSets which share the same PeriodType.  Given that some
> of those do exist (the bad practice) then it is considerably better to
> rename (and re-id) the dataElement.  This will anyway be necessary if
> DataElements become directly associated with PeriodType.
>

Yes but this is exactly why we want to do this - create the mentioned
application enforced constraint. Firstly there is no constraint saying a
DataElement MUST be a member of a DataSet. Secondly we are making things a
whole lot easier by making this association explicit; think of assigning
data elements to datasets (are the dataelement already a member of another
DataSet with a different PeriodType?), gap analysis, regression analysis,
datamart (which PeriodType is the DataElement associated with?), alignment
with the lecacy DHIS 1.4 model (how do we manage import?).

I agree that there is a slight redundancy associated with this, but I think
what we gain in regard to simplicity and performance exceeds the minor cost
of this association.


>
> I think the only other thing which is achieved by associating the
> PeriodType with the DataElement is that it would allow for DataSets
> which a heterogenous mix of DataElement PeriodTypes, which I don't
> think is a design goal.


This is definitely something we don't want to allow.