First off let me just say that I'm new to LLBLGen so bare with me

I'm just curious if this scenario is possible. In the adventure works SQL example database the employee table has effectively a 1:1 relationship with the contacts table. I've found I can I make an "employee" entity that has fields from the contact table (firstName, lastName, etc). If I do this will the framework know how to insert a record in the contacts table when saving my new employeeEntity? Or must I explicitly tell it how? Additionally will the framework know to update both records automatically?

That is, Can I do this:

Dim emp as new employeeEntitiy

emp.NationalIdNUmber = 2345 emp.Title = "some title" ... ' fill other properties

emp.FirstName = "myFirstName" ' stored in contact table emp.FirstName = "myLastName" ' stored in contact table

emp.Save()

Or must I do this: (change the model so that it has a contact child entity)

Dim emp as new employeeEntitiy emp.NationalIdNUmber = 2345 emp.Title = "some title" ... ' fill other properties

dim cont as new contactEntitiy cont .FirstName = "myFirstName" cont .FirstName = "myLastName"

emp.contact = cont

emp.Save()

The contacts table exists for normalization purposes. I'd like to design the entity model and forget about how things are normalized. With the latter approach I have to remember that the contact and employee are separate when logically they are not. The first way didn't work when I tried it but I could be doing somthing wrong. Just wanted to see if this works in theory.

Thanks for the help, Dane

1:1 relationships can be modeled using entity inheritance. search the docs/forum for "Entity Inheritance"

Dane wrote:

The contacts table exists for normalization purposes. I'd like to design the entity model and forget about how things are normalized. With the latter approach I have to remember that the contact and employee are separate when logically they are not. The first way didn't work when I tried it but I could be doing somthing wrong. Just wanted to see if this works in theory.

Just my opinion here, but . . .

If contact information is inherently part of the employee, there is no reason to have it in a separate table. If it seems natural to you to access the contact information directly, but you are having to fetch it from another table, it's likely that your model does not correctly represent your design.

If you have exactly one contact for every employee, and if that contact info won't be used for anything else, then it probably belongs in the employee table. Pulling the contact info into another table does not make your model more normalized--in fact is can add complexity where none is required (it will also degrade performance, but probably not much in the case you described).

Take this with a grain of salt, of course, since I'm sure there is much more to what you are doing than what you posted. But I've seen cases where developers get too enthusiastic about "normalization", and misapply it to mean abstracting out entities that share common fields, which is not the point of normalization at all.

(If you're committed to having contacts in a separate table, you might look at adding your own code to the entity to accomplish this transparency. )

Phil

Thanks for the input guys.

Since this is a little bit theoretical for me I really don't have any real code to ask questions about. But I think I made a mistake in asking my first question. Below is a bit of a revision:

I guess what I'm asking is if the framework will understand what I'm doing if I flatten the table hierarchy into 1 entity. That is if "employee" has 2 references to the contact table, we'll say hiringAuthorityId and RefferedById, can the employee entity have "HiringAuthorityFirstName" and "RefferedByFirstName" fields that map directly back to the contacts table? Will the framework automatically track/insert new pks in the contacts table?

Inheritance would work great if the contact information was for the employee his/her self. but, as noted above, I'm talking more about "has a" type relationships.

This probably weird. I'll likely just stick to the latter approach mentioned in my first post. I was just curious how far I could take it.

Phil, I def agree, I've caught myself over normalizing more than I'd like to mention. I've gotta keep reminding myself why I'm normalizing . In the new example though am I think its ok to call these things 2 separate entities and not really _a part of _but rather referred to by the employee entity. Right?

Dane wrote:

I def agree, I've caught myself over normalizing more than I'd like to mention. I've gotta keep reminding myself why I'm normalizing . In the new example though am I think its ok to call these things 2 separate entities and not really _a part of _but rather referred to by the employee entity. Right?

Yes. From your description it sounds like there is more to it than your original post implied. So pardon my ranting.

Phil

Oh don't worry about it at all, its a valid concern. Any input is greatly appreciated. Thanks for taking the time out.