<-- 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.
>

Your approach is more appropriate with cases when the design is stable. But what happens if you have an incremetal design? And then what happens if you have thousands of installation for the same application but with different customization for each client? How do you keep track of both, the original schema and the customized ones?

<-- 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 writing a lot of code is what concerns you, there are code generators. In fact, the solution is very simple: the schema builder I keep talking about. We are not inventing anything here. XSD schemas are extensible by nature. All we have to do is to tell the schema builder the physical table name and field names, and it will generate the appropriate create, alter, drop, insert... statements (or SPs).

<-- 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.
>

The physical table/field names are kept in the schema along with the logical names. Given those, the rest is simple math. We have developped another approach. In the schema we define the physical tables and their relationships. We mark those tables as "abstract" (so they cannot be used). We then define a another table, we call "view". We can only add existing fields from other tables to this view; with one exception; expression fields, just like in databases. Now when we need to fill the data, a specialized data adapter should recognize the view's existence and should be able to fill it according to the schema of the original tables.


<-- Have you had any issues with performance or ease of reporting using your inheritance mapping?>

First, if you want flexibility there should be some tradeoffs, which is in this case performance. But we manage this by keeping the heirarchy as shallow as possible (3 levels max). Also, the resulting table partitioning should speed things up. For example, we could read information from the parent (or child) table (which is smaller in this case) only if all the requested information is lying there. Not to mention reducing table locks while writing and many other benefits. This I think will make up the difference.

Regards