On May 17, 2009, at 6:23 AM, Miguel Lopes wrote:
> I understand what you mean and, given I don't know Dabo I'm probably
> wrong.
> But the bizobj also encapsulates relationships and this sparks the
> need for
> several bizobjs from the same table, or not? Let me give you an
> example:
>
> account.account_id = contact.account_id (1 Account, M Contact)
> opportunity.opportunity_id = contact.opportunity_id (1 Opportunity, M
> Contact)
>
> So contacts are assigned to Acounts, but they may also be assigned to
> Opportunities.
IMO, that sounds like a poor data design. Perhaps there was a reason
for doing it that way, but an account and an opportunity are the same
thing; the difference is simply a matter of time. In systems I've
designed, you would have a customer table with a way to distinguish
the two states: either a bit field, or simply links to related tables
that hold the additional columns that need to be tracked for an
opportunity and an established account.
With this design, Contacts are assigned to a Customer when the
Opportunity is first created. When that is converted to an Account,
nothing needs to change on the Contact side: they still work for the
same company; that company is now an Account and no longer just an
Opportunity. You would also not need two contact bizobjs to represent
what is actually a single relationship.
Does that make sense in your situation?
-- Ed Leafe
_______________________________________________
Post Messages to: Dabo-users@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message:
http://leafe.com/archives/byMID/9f4f94aa-f400-41d9-9d9f-d652ac7b4...@leafe.com
