dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

OK, good to hear. As long as it is not a naming convention but I will
go ahead and vote early just in case.

There are multiple Pickens Counties (one in Alabama, Georgia and South
Caroina respectively), and you are right, we have multiple KFCs in
each. If I want to record the total number of chicken dinners sold in
each, I would need to invent some naming convention to get around the
data model. This is really a separate issue I guess, but my point is
that the data model should capture reality, rather than imposing an
alternate view of it.  Just say no to naming conventions (and KFC!).

Regards,
Jason

In general they all suffer from the performance impact of
> long strings.  Which is why I favour the use of a short string or code
> internally, which can be concatenated to a longer namespaced uri when we
> have to interoperate between systems.  But that solution is not perfect
> either.
>
> Cheers
> Bob
>
> PS.  I would have though of Georgia as more of a KFC county than a McDonalds
> one.  Similar problem mind you :-)
>
> 2009/9/28 Jason Pickering <jason.p.pickering@xxxxxxxxx>
>>
>> If we are voting here, I would say that any naming convention should
>> be avoided  costs, as they tend to be rather arbitrary, and
>> easily manipulated.
>>
>> I am also much against the unique name restriction currently imposed
>> in the data model. We have situations where there identially named
>> facilities within the same organizational unit (think of McDonalds
>> here). I think DHIS is even more restrictive that this example. I grew
>> up in Pickens County, Georgia. There is no reason why there cannot be,
>> or should not be identically named organization units. DHIS 1.4 gets
>> around this by the use of naming conventions, which causes me no end
>> of headaches when I have to produce a report. I suppose the same could
>> apply to other concepts, such as "Age".  They should be able to be
>> distinguished through other means.
>>
>>  I am not sure if a UUID is the best way for this, as it does have
>> potential performance implications, but it is certainly preferably to
>> any naming convention that may be enforced through the UI and not the
>> DB.
>>
>> Regards,
>> Jason
>>
>>
>>
>> On Mon, Sep 28, 2009 at 3:53 PM, Jo Størset <storset@xxxxxxxxx> wrote:
>> > Basically I agree with you, just one minor opinion :)
>> >
>> > Den 28. sep. 2009 kl. 14.36 skrev Bob Jolliffe:
>> >
>> >> What seems to then happen is that implementors tie themselves up in
>> >> knots
>> >> trying to find new and imaginative ways of naming the "Age" categories
>> >> so
>> >> that they are unique from one another when there is really no
>> >> compelling
>> >> reason to this.  With a structure like:
>> >>
>> >> <category id="23" name="Age" uid="4454545656456477756" />
>> >>
>> >> where id is just the internal key and uid is a unique identifier (which
>> >> could be a uuid but not necessarily) then there is really no reason not
>> >> to
>> >> have any number of categories with the name "Age" where each one has
>> >> different sets of category options.
>> >
>> > The problem with non-unique names is that you can easily get into
>> > unintended
>> > situations where the name is displayed in a context where the difference
>> > between "versions" is important for the person using the system. I don´t
>> > really know dhis well enough, but I have seen this kind of problem other
>> > places.
>> >
>> > Jo
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~dhis2-devs
>> > Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~dhis2-devs
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>
>