> > > You are right that not having a reverse association makes selecting > all the "unassigned" DataElements a bit tricky. Perhaps the most > robust solution is to have a default unassigned DataSet - with a NULL > periodType. All new DataElements start life in this DataSet. This > makes finding the available dataElements pretty trivial and we can > also rigorously enforce that a dataElement MUST be a member of a > dataSet which is a good thing.
This will be a complexity trade off between data model / database schema and application logic. Getting DataElements for a PeriodType will definitely involve a more complex and slower query or additional application logic. As for accidental complexity / future implications the DataElement -> PeriodType association has been in use in DHIS 1.4 for several years and proved to be working. What do we know about this approach? > > > You might be right on the performance of dataMart etc. It will really > come down to how often you have to call getPeriodType() which > shouldn't be too much - the real data crunching meat is in the > datavalues not the dataelements I think. If indeed it proves very > costly then it might justify the hacking the schema, but I think we > should try implementing at the API level first. Reimplementing > DataElement::getPeriodType() can be done if necessary. > I guess Hibernate will cache the DataSet lookup anyway. But remember we cannot implement getPeriodType in the DataElement object if there is no association DataElement -> DataSet. > On second pass this is actually quite trivial to implement because we > have the go-between DataSetMembers(?). Finding the DataSets > associated with a DataElement should be as straightforward as finding > the DataElements associated with a DataSet. Yes, but "datasetmembers" is a mapping table in the database, we still need an association in the object model. The "implicit" approach can be done, but it involves a DataElement -> DataSet association, and more complex queries/programming model. (If the DataElement -> DataSet association is omitted; a call to the service layer to get the PeriodType for a DataElement.) The "explicit" approcah also involves an association (DataElement -> PeriodType). I am not sure if one could say it involves redundancy, as we don't have a model enforcement of one-or-more DataSet memberships for a DataElement. I opt for the latter approach. Of course I might be wrong:)
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
