On Aug 11, 2009, at 6:42 AM, Gustavo Pizano wrote:
sorry keepin gin the lsit.
On Tue, Aug 11, 2009 at 12:41 PM, Gustavo Pizano <email@hidden> wrote:
Ahmm so I can relate Area to itslef?
interesting.. well I guess in the java class will be something like \
public Area ....
private NSArray <Area> areas...
or something like that.
Yes.
Call the Area.parentAreaId -> Area.areaId relationship "parentArea"
Call the Area.areaId -> Area.parentAreaId relationship "childAreas"
you'll have the following methods in your Area.java class:
public Area parentArea()...
public NSArray<Area> childAreas()...
(plus all the various setters and fetch stuff generated by the templates)
another thing, but in the db I will need 2 tables isn't it? one area and anotherone SubAreas, I hadn't made such a inheritance in a relational world.
Do you really need inheritance? Do "sub" Areas _really_ have differences from an Area? If so, do those differences _really_ require you to treat them as different classes?
Inheritance should by your absolute last choice. It is needed in some situations, but you really should try to avoid using it unless it is truly required. I've often used inheritance too quickly and ended up painting myself into a corner later in the development process and wishing I had used a different design pattern to meet my needs instead of inheritance.
If you really do need inheritance, then you need to pick from the 3 different strategies for creating the inheritance structure in the DB. Single-Table Inheritance (most likely the best choice, one table that holds data for the super and all subclasses), Vertical Inheritance (one table for the super, one table for each sublcass. Be forwarned, it's not often used so there is not a lot of support out there. Hi Lachlan) or Horizontal Inheritance (one table for each subclass).
HTH,
Dave