The main problem is that ContactInfo is not used by only the Employee Entity, that is why I am not sure how to design it on the database side. Also, specifiying JUST 3 Contact Infos for the Employee does not work since the user must be able to add and remove from the contact info as a list. Same goes for Address table, it is used by more than one entity and probably by the same entity more than once.
On Sun, Aug 15, 2010 at 12:33 PM, Frans Bouma <[email protected]> wrote: > > I have a ContactInfo Table : > > ContactInfo( > > ID int IDENTITY(1,1) NOT NULL, --PK > > ContactValue varchar(100) NOT NULL, > > ContactType smallint] NOT NULL > > ) > > In my model multiple entities/tables would need to have a list of > > ContactInfo entries. > > Example: > > > > Employee has 3 contact infos: 1 email and 2 phone numbers. I would then > have > > a ContactInfo with ContactType = 2(email), and 2 ContactInfo with Type = > > 1(phone). > > ContactInfo isn't an entity. An entity is a group of attributes > (fields) with its own identity. Your contact info isn't that, it's 1 value. > > So I'd model it as a Component, and define 3 contact infos in > Employee. This is less flexible (you can't add more without modifying > employee), however it's IMHO better, because you're not going to re-use > contactinfo. It's the same as address. A lot of people model that as a > separate entity, which is in most cases not really beneficial, as you don't > re-use entity instances (rows in the table) > > > FB > > > Now the question is how to link this Entity to the different users? It > looks > > like inheritance with only a difference in foreign keys. Does adding an > FK > > to every user Table make sense / good design? > > > > Also, how do we represent such a thing in the domain model? Do we create > > duplicate classes for every use? EmployeeContactInfo, ClientContactInfo, > > etc... How do we map those? > > > > I know those are a lot of questions but I think the idea is clear enough, > > thanks for the help in advance. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "nhusers" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<nhusers%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/nhusers?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
