Hi,

I've got the following scenario:

I have a "Contact" table containing contacts related to "Customers". These contacts are used at multiple points, for example for registering emails received from a customer, or other correspondence.

Now we want to extend our application to manage courses for the Contacts (employees of our customers) of our Customers. A lot of the current contacts will never get a course, but the ones who do will need some additional attributes & relations.

Some examples or relations & attributes: Additional Attribute: - StudentNumber (this is a number which will and should only be given to employees who get a course) Additional Relations: - Courses (relation to the courses the follow(ed)) - Certificates (relation to the certificate(s) the have receveided for completed courses)

I've been looking at Entity inheritance and it seems to be a scenario for "TargetPerEntity" where we would create a table Student with the following fields: Student.ContactId Student.Number And a relation Student.ContactId (N:M) Course.CourseId

Some questions I have now are: - Is this the kind of scenario for using TargetPerEntity Entity Inheritance? - What happens to overviews, would a ContactCollection still contain all Contacts or only the ones which are not students? (Can/would I still retrieve Students also a ContactEntities?) - Would I still let the user edit a Contact/Student via my standard Contact Editing screen, or do I now need a ContactEdit & StudentEdit screen in which all fields, except for the additional attribute & relation, are the same? (Or of course some smarter screen which shows/hides fields based on the entity type)

Any input on this would be greatly appreciated.. I've been reading the manual over and over again to get the concept, but couldn't find answers to this on the forum or in the manual.

Thanks a lot!

Gab

Is this the kind of scenario for using TargetPerEntity Entity Inheritance?

I think not (IMHO). Because Entity Inheritance doesn't allow a created entity to change its type. i.e. You can't have a Contact entity and then change it to be a Student Entity. So if an employee was once a contact, can't later on be a student. That's why entity Inheritance doesn't fit your scenario.

Still you may use a 1:1 refrential relation between Contact & Student.

If I have Contact which I indeed want to turn into a Student later can't I just create a 1:1 related StudentRecord for the Contact I want to be able to use as a Student?

Like this:

Before: [Contact] ContactId = 5 | Name = Peter ContactId = 6 | Name = John

[Student] <empty>

After: [Contact] ContactId = 5 | Name = Peter ContactId = 6 | Name = John

[Student] ContactId = 6

Wouldn't a StudentCollection.GetMulti(null) return 1 student, being John?

Attached is a screenshot of the relevant Database diagram & the view in the LLBLGen Designer

Thanks.

If I have Contact which I indeed want to turn into a Student later can't I just create a 1:1 related StudentRecord for the Contact I want to be able to use as a Student?

Yes you can, but this will be a refrential relation not an Inheritance one.

With a refrential relation when you create a new Student entity and save it, it will only Insert in the Student table.

But in an inheritance relation it will ateempt to Insert a new record in the Student table as well as in the Contact table.

Okay, so these relations in the LLBLGen Designer work only one way?

What would I need to change to make it work like you now said, that creating a Student would cause creating a Contact? I might change the scenario in that case...

Thanks again for your input..

Cheers, Gab

If you define a Target Per Entity Inheritance relation between the 2 entities, saving a Student entity will Insert a record in its super type entity (Contact).

But you just mapped the entities with the default 1:1 refrential relation being detected or defined, then you can insert a Student that refers to an existing Contact, and thus the StudentEntity won't inherit from the ContactEntity.

I've then misunderstood the manual.

Can you tell me which paragraph tells me how to do this, or give a short bullet list of steps that I would have taken if this would be created from scratch in an empty database & empty llbl-project,

Thanks.

I've then misunderstood the manual.

Can you tell me which paragraph tells me how to do this, or give a short bullet list of steps that I would have taken if this would be created from scratch in an empty database & empty llbl-project,

Thanks.

The database design is the same in both cases (1:1 relation).

SuperEntity

Id (PK) SomeFields

SubEntity

Id (PK & FK to the SuperEntity's PK) OtherFields

The difference is whether you will define an Inheritance Hierarchy in the LLBLGen Pro Designer or not.

Please check the LLBLGen Pro manual's section: Designer -> Inheritance mapping

Thanks!