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