I don't see where Houssam mentions ORM but the data structures he describes are one possible relational mapping of inheritance modeled in ORM. I agree with Houssam's evaluation that these structures are often better than modeling inheritance using flatter structures.

jMM

>>
>>We use one-to-one to mimic class inheritence in database. So, for each entitry class there is a corresponding data table in the database. Child classes will have their one tables, and these are linked to their parent tables by foreign keys. we use inner joins in select statements, and wither an update statement for each table, or SPs for databases that support them. We find this approach is the most natural fit between relational databases and OO programming.
>>
>
>Interesting! ORM is currently of great interest to me.
>
>So, for example you might have an abstract person class with student and teacher as subclasses and for data tables you would have person, student, and teacher with a fk relation between the subclasses and abstract parent class?
>
>As I mentioned in another post, the most natural fit (read as "the easiest way") is to have one business object per concrete domain class. As I'm sure you found out you would have to write a lot of code to maintain the inheritance relationship inside the database tables. For example, adding a new student requires an insert into two different tables, student and person. MM.NET knows nothing of this relationship.
>
>If you are using inner joins to retrieve the data then you need to pull it apart when you do the update, right? How do you decide which fields of the joined table belong to which table? For joined tables we are using the BusinessObject.UpdateSelectStatement to update a single table on the back end. The other way is to retrieve both tables into the same dataset and set up a DataRelation. This works well with lookup tables.
>
>Have you had any issues with performance or ease of reporting using your inheritance mapping?