I have looked at the tutorial on inheritance hierarchies "Designer: Inheritance mapping"

It looks like a good idea but I have no idea what is happening internally.

It looks like there is a higher level abstraction being applied to an exiting entity/table on the database based on discrimination fields and values giving rise to subentities.

Is that correct or is something in the database itself?

Is it possible to get a copy of the actual database that is used in this tutorial. That might clarify things a bit.

Are the sub entity types persisted into the database schema or only within the LLBLGen Pro project.

Its a little hard to follow as I think the tutorial assumes some prior knowledge with earlier versions of LLBLGen Pro while for a complete newbie (like me) the concepts are not that clear.

You should start by reading Concepts - Entity inheritance and relational models

Walaa wrote:

You should start by reading Concepts - Entity inheritance and relational models

Fair enough but for a newbie its still hard going (I have only been acquainted with LLBLGen Pro for 3 1/2 days) and I think I have made fairly good progress. The current tutorials are good but are fairly basic, the user guide is aimed at a fairly high level, some more advanced tutorials that cover the middle ground would be good.

Is it possible to get a copy of the database used in the

Designer: Inheritance mapping This video shows how to map inheritance hierarchies of entities in the LLBLGen Pro designer. Continues from the previous tutorial.

Click here to open the Inheritance Mapping tutorial (opens in new window)

**That would really make things a lot simpler if one was able to reproduce what ones sees in the tutorial. **

As you support a number of database engines that might be a bit of a challange but the tutorial used SQL server and one can use a free version if necessary.

PS: I Understand the ORM model. I think it is a very good technique but what I am missing is how this translates to an actual database schema. Having access to this should help clarify things a lot.

he00273 wrote:

PS: I Understand the ORM model. I think it is a very good technique but what I am missing is how this translates to an actual database schema. Having access to this should help clarify things a lot.

Don't worry about the above request (although it would be nice) I think I have it figured out now. I created an employee table as such

CREATE TABLE [dbo].[Employee]( [EmployeeID] [bigint] IDENTITY(1,1) NOT NULL, [EmployeeName] nvarchar NOT NULL, [EmployeeAddress] nvarchar NOT NULL, [EmployeeDOB] [date] NOT NULL, [EmployeeGender] char NOT NULL, [EmployeeType] [smallint] NOT NULL, [DepartmentID] [bigint] NULL, [CarTypeID] [bigint] NULL, CONSTRAINT [PK_Employee] PRIMARY KEY CLUSTERED ( [EmployeeID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY]

The discrimination field is EmployeeType Managers have DepartmentID mapped BoardMembers have CarTypeID mapped

I presume one should index the discrimination field (attribute).

I am very interested in this as I have a very good use for it.

I think a tutorial walking one through this would be great (in addition to the video).

Its hard work learning this stuff.

When you talk about a cabrio I presume you mean something like a Mini Cooper Cabrio (I am not up with sports cars).

Its hard work learning this stuff.

Just a small learning curve.

Also it's worth mentioning that there are 2 types of inheritance (TargetPerEntityHierarchy & TargetPerEntity).

What you have examined so far is the first one, where all the entities in the hierarchy are mapped to one database table.

The other type can be described with the following example.

Person
---------
PersonId (PK)
FirstName
LastName
BirthDate

Employee
------------
EmployeeId (PK, FK to PersonId)
HireDate
DepartementId
....OtherFields

Manager
-----------
ManagerId (PK, FK to EmployeeId)
...OtherFields

The above database schema describes 3 tables in the database, where the Manager table inherits from the Employee table which in turns inherits from the Person table. And hence the name "Target (table) per Entity".

Thanks for the clarification

I noticed that there four possibilities in

Comparison of inheritance mapping with competing O/R mappers Inheritance is an important part of most modern O/R mapper frameworks. Because O/R mapping is a generic technique with a wide variety of detailed descriptions, it can be confusing what each mapping strategy means and how it compares to another O/R mapper's way of mapping inheritance.

LLBLGen Pro only supports the first 3