Design tips needed. Can I get your opinion on this?

Jaymer

I'm wondering how you folks would handle this in AIM. Am I on the right track?

I need to store multiple documents in this system... PDFs, emails, images, Word docs.

I have 3 main BOs that can own a Document: (examples)
Opportunity - can have misc email correspondence (images, PDF)
Vendor - tech bulletins specific for vendors (PDF)
Customer - yearly tax exempt form (PDF)
and a BO
MyDocument

In each main BO, I can have this attribute: om_MyDocument

-----> In MyDocument, should I have 3 reference fields back to the possible owner?
MyDocument.ps_Opportunity
MyDocument.ps_Vendor
MyDocument.ps_Customer

with 2 of them remaining UNDEFINED, and 1 points to the owner.
If the customer requirements change, and other entities in the system need to have documents attached to them, I'll just add more references back to the new owner...
MyDocument.ps_AnotherBO

EDIT for Clarification
1) A MyDocument will only be owned by ONE BO (If its a Tax form, then its related to the Customer, If its a PO, then its for a Vendor.)
2) All MyDocument are unrelated to each other - I just don't want to have 3x+ duplicate code to manage the same data.
3) For viewing, I might be on a Vendor, and want to see their Tech Bulletins - which would easily list in a grid widget. Likewise other BOs.
4) I can't just rely on om_Document to be able to find child documents given a known Parent. I will want to view MyDocument to see all Tech Bulletins, for example, so it must point ALSO to a logical owner. I can't have these "ob", because then a MyDocument would be owned by [at least] 3 parents (not allowed), which is why they are "ps" to point to 1 parent.

any thoughts?
thx
jaymer...

PointsWell

You will get into problems if you have a BO with multiple owned by.

If you need to have it as OB and you need to look at all the documents all at once I would make a BO Group called Documents

I'd then create 3 BOs under that
OpDocs
VendDocs
CustDocs

Each of these need to have common fields such as File and ob_Contact but then each can have their own relationships back to their source.

The question I'd ask is if I were to delete a BO higher in the hierarchy, what underneath it should also be deleted (i.e. if I didn't delete these records would they be orphaned).

If the Docs relate to the Opportunity, for example, and are meaningless without that opportunity, then I would create a BO OpDocs with attribute ob_Opportunity and Opportunity with an attribute om_OpDocs. I'd then populate the OpDocs with a ps_Contact so you can see that underneath the Contact record (if necessary).