views:

547

answers:

3

I'm attempting to model a grocery store. In the store, there are several "aisles". Each "aisle" has a group of "categories" of "items" it stores. Each "category" can only belong to one "aisle". Each "item" can only have one "category".

The data model seems straight forward to me:

  • An "aisle" table with an ID and DESCRIPTION
  • A "category" table with an ID, NAME and an AISLE_ID that refernces the "aisle" table
  • An "item" table with an ID, NAME, DESCRIPTION and a CATEGORY_ID that references "category"

The object model is where I need help:

  1. An Aisle object can have a list of Category and Item objects within it.
  2. An Aisle object can have a list of Category objects. A Category object can have a list of Item objects within it.
  3. An Aisle can have a list of Item objects. A Category object can have a list of Item objects.

In each case, an Item will logically have a Category object within it. I have a DAO for each domain object, so depending on the way it's done, the sql changes a little. Any thoughts?

+1  A: 

I vote for choice #2. Makes more sense than #1 or #3.

Do you think the relationships need to be bi-directional? Should an Item need to be able to figure out who its parent Category and grandparent Aisle are?

duffymo
@duffymo That's a very good question. Right now my model supports bi-directional relationship between a Category and an Item. It get's a little funky since it will form a cyclic relationship :S I might need to include only "shallow" relationships in which an Item has a Category, but the Category is only populated with it's ID and NAME and *not* all the items that fall into that category. What do you think of that?
djunforgetable
@dj: Then it's definitely #2, because that way you can have a Category with an empty List. "inverse=false" breaks the cycle from Hibernate's point of view.
duffymo
@duffymo when I load the data from persistance, should the entire structure be present? For example, when loading an Aisle object, should all the Categories contained within it have all Items contained within the Category?
djunforgetable
Depends on how many you're talking about. If the number becomes a problem, I'd say they're candidates for lazy fetching. Just fetch the ones you need from the persistence tier.
duffymo
+1  A: 

I would go with choice #2.

An Aisle's main concern is which Categories are contained within it. It should be up to the Category class to determine which Items are members. This keeps the levels of abstraction consistent in each object - where Aisle is the higher level object, Category is a slightly more detailed level and item is the most granular.

MikeG
+1  A: 

Number 2 makes most sense if those are your only 3 options.

I think, if I were to create this model, I would use the following model (small modification, just trying to remain as close to your ideas as possible):

An aisle object can have a list of category objects, a category object can have a list of item objects within it, and an item is associated with a category AND an aisle.

My modification seems to be more on the data side.

The reason I would have done that, is because, someone says "hey I'm looking for this particular item, which aisle is it in?" -- 1 lookup would give you the answer. whereas with your data model, you would need 2 lookups.

At least that's how I think of it.

Sev
@Sev I would agree with you. My comment would be along the lines of my comment to duffymo up top in that it might make more sense to keep a "shallow" relationship whereby the composed object doesn't contain any further composed objects.
djunforgetable