I did not go beyond mentioning inheritance because I did not want to
influence your eventual implementation of the solution which I
suggested i.e. have a separate EntityContactInfo for each Entity that
uses the ContactInfo.
Inheritance is one of the ways to implement it. You could also use a
contained reference where the EntityContactInfo would have a reference
to the ContactInfo which would actually have avoided the problem you
ran into because you would have a separate mapping and table for each
EntityContactInfo. I initially thought there would be problems with a
bidirectional association with this approach but I'm not sure about
that anymore. However I still don't like that for each new
EntityContactInfo you have to touch the ContactInfo mapping to add the
new EntityContactInfo reverse mapping.
The above approach is virtually the same as using table-per-concrete-
class inheritance mapping which may actually be better.
The approach you tried to implement is the table-per-hierarchy for
which you will need a separate column in the ContactInfo table for
each Entity that uses ContactInfo and not one EntityID for all
entities as you attempted to do.
ContactInfo
ID int
EntityType char(1)
EmployeeID
CustomerID
SupplierID
....
ValueType smallint
Value nvarchar(50)
You can also use the other table-per-class at the expense of more
joins and other additional issues. However the weakness with the
inheritance approach is that you are basically mixing two separate
inheritance hierarchies which you'll see in the above and your table
definition where you have both EntityType and a ValueType columns in
the table. This basically means you have given up the choice of
extending by inheritance the types of ContactInfos you will have i.e.
PostalContactInfo, EmailContactInfo, PhoneContactInfo etc.
The containment approach avoids this mixup and allows you to extend
both ways.
I hope I have been specific enough without unduly influencing your
implementation. I would also like to see how your approach because it
may provide new ideas.
Jide
On Aug 16, 8:27 pm, Muhammad Shehabeddeen
<
muhammadshehabedd...@gmail.com> wrote:
> I re-checked what you had posted, and I agree you kind of mentioned
> inheritance in your post, but you did not show the design for the tables
> which is the real CATCH here since I am using a single column as a shared
> FK. Please correct me if the coffee has not kicked in yet :)
>
> On Mon, Aug 16, 2010 at 10:23 PM, Muhammad Shehabeddeen <
>
>
>
>
muhammadshehabedd...@gmail.com> wrote:
> > Jide,
> > This implementation is different from the one in the other topic (it uses
> > inheritance and a discriminator) and that is why I decided to post it in a
> > separate question. This is one implementation suggested by a friend, and I
> > was not asking how to implement the concept, I was just asking why the
> > implementation was flawed. In anyway, I can link to it if necessary.
>
> >> <
nhusers%2Bunsu...@googlegroups.com<nhusers%252Bunsubscribe@googlegroup
s.com>
> >>
http://groups.google.com/group/nhusers?hl=en.- Hide quoted text -