Data Model:

[Anthony]

On Apr 13, 1:26 am, Peter Otten <__pete... at web.de> wrote:
> Anthony wrote:
> > On Apr 12, 7:46 pm, Aaron Watters <aaron.watt... at gmail.com> wrote:
> >> On Apr 12, 10:14 pm, Anthony <alantho... at gmail.com> wrote:
>
> >> > I'm struggling on whether or not to implement GroupItem (below) with
> >> > two separate models, or with one model that has a distinguishing key:
>
> >> > Given:
> >> > class ParentGroup:
> >> > a group of values represented by class GroupItem
>
> >> > class ChildGroup:
> >> > a group of values represented by class GroupItem
> >> > foreign-key to ParentGroup (many Children sum to one Parent)
>
> >> > Option A:
> >> > class GroupItem:
> >> > foreign-key to ParentGroup
> >> > foreign-key to ChildGroup
> >> > GroupItemType in (ParentItem, ChildItem)
> >> > value
> >> > value-type
>
> >> > Option B:
> >> > class ParentGroupItem
> >> > foreign-key to ParentGroup
> >> > value
> >> > value-type
>
> >> > class ChildGroupItem
> >> > foreign-key to ChildGroup
> >> > value
> >> > value-type
>
> >> > What are my considerations when making this decision?
>
> >> > Thanks!
>
> >> It looks to me that the two designs
> >> might be useful for different
> >> purposes.  What are you trying to do?
>
> >> -- Aaron Watters
>
> >> ====
>
> whiff.sourceforge.nethttp://aaron.oirt.rutgers.edu/myapp/root/misc/erdTest
>
>
>
>
>
> > The group values represent statistics that I'm tracking, based on
> > activity groups.  Some samples:
>
> > Group: Johnson, Total Units Produced = 10, Total Units Consumed = 5
> > Chris Johnson, Units Produced = 6, Units Consumed = 3
> > Jim Johnson, Units Produced = 4, Units Consumed = 2
>
> > Group: Smith, Total Units Produced = 15, Total Units Consumed = 8
> > Mark Smith, Units Produced = 7, Units Consumed = 5
> > Bob Smith, Units Produced = 8, Units Consumed = 3
>
> > The groups will be responsible for entering their own statistics, so I
> > will have to do some validation at data entry.  The ability to create
> > new statistic types (e.g. Units Broken) for new groups in the future
> > is important.
>
> > What would be the advantages of using option A versus option B?
>
> I may be missing something, but your example looks more like option C:
>
> class Group:
>     name
>
> class Member:
>     group # foreign key to Group
>     name
>
> class Item:
>     member # foreign key to Member
>     type
>     value
>
> You can calculate the totals for members or groups on the fly; the classical
> tool would be a relational database.
>
> Peter

You're absolutely right.  This is also probably why I'm struggling
with my two options, with neither one of them "feeling right."

What got me going down this road is the fact that users will almost
always only have the total level values to work with.  The detail
entries would be almost optional, from their point of view.  This
means that if I were to set it up as option C, then the default data
entry use case would be to set up an "Unregistered" instance of the
child.

Now that you've highlighted that important point though, it seems to
me like the proper course to follow.  It implies a little bit of
redesign on my part, but better now than further down the road.  I
just need to make sure now that there are no exception cases for top
level calculation:

i.e.

Most of the time:

Total Units Consumed = sum of (all Child Units Consumed)


I need to develop a contingency plan for when the top level is not a
straight sum of the child levels.