On 4/05/2010, at 2:22 PM, Bob Morley wrote: > Scott Gray-2 wrote: >> >> I think you missed the second half of my earlier email: >>> 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. >> >> Employment already has the same PK fields as PartyRelationship. >> > > Yep; I had definitely glossed over that. In my head I was thinking that > PartyRelationship had a partyRelationshipId that could be added to > Employment and Employment could have those other fields removed. But you > are quite correct, we could simply use the existing primary key fields. > > Would there be any thought to doing the former? I don't think I want to > bite that off to be honest, but one could create the entity such that it has > a single primary key and the others would make up a unique index. > Personally, I don't know if that is a good idea but it would reduce > redundancy in the sub-classes.
Personally I like using natural PKs whenever possible and the number of them doesn't really bother me with all the tools we have for auto-setting fields. It would be interesting to see if there is some way to smarten up the entity engine so that these sub-types could be more deeply integrated. I have no idea at the moment what form that might take though. Regards Scott
smime.p7s
Description: S/MIME cryptographic signature
