On 1/05/2010, at 3:52 AM, Adam Heath wrote: > Scott Gray wrote: >> I think Agreements are more like the terms of a relationship and can change >> over the course of that relationship. >> >> I would tend to think of an account number as being more like relationship >> meta data that exists so long as the relationship exists and for that reason >> I would either add a generic field to PartyRelationship or otherwise add a >> new entity SupplierRelationship and one-to-one it with PartyRelationship. > > I like the latter, SupplierRelationship, as there could be an > unbounded set of SupplierIdentificationType and > SupplierIdentificationPurpose fields.
That wasn't what I was suggesting, I was describing SupplierRelationship as being an extension to PartyRelationship in the same way that Person or PartyGroup extends Party. > Type has IDENTIER as a parent, then SECURITY_CARD, EMPLOYEE_ID as > children. > > And, in that vein, SECURITY_CARD could very well change over time too, > separate from the parent PartyRelationship. I'm not sure how I would handle something like a security card but IMO the Employment entity should be an extension to PartyRelationship, I mean it already shares the same primary key fields. Regards Scott
smime.p7s
Description: S/MIME cryptographic signature
