Inheritance - Overview
Telerik Data Access Fluent Mapping API offers a couple of different ways to ultimately model inheritance hierarchies. The simplest, most straight-forward approach is to use vertical mapping. With vertical mapping each class has its own table containing only its fields. That strategy is also known as "table-per-concrete-class" model. Each concrete persistent class in the model is persisted to its own table. For example, a Customer object is stored in the Customers table.
The second of the three choices for modeling inheritance in the database is to use Flat mapping. With flat mapping, fields from the subclasses are mapped to a superclass table. Flat mapping is the simplest and is usually the fastest option so it is the default. In Flat mapping, the entire class hierarchy is persisted to a single table. That includes everything from an interface/abstract class at the top, all the way down to implementation classes at the bottom. This actual works by extending the table to include additional fields needed by the subclasses. Also you need to provide a "discriminator" column to tell Telerik Data Access which rows for which classes are.
The third choice for modeling inheritance in the database is to use Horizontal mapping. Horizontal inheritance can only be enabled for the topmost class in a hierarchy. Each immediate subclass is stored in its own table with a "copy" of the fields from the superclass. A horizontally mapped class itself, i.e. the superclass, does not have a table. Therefore, a horizontally mapped class cannot be directly persisted; only subclasses of the class can be stored in the database. For this reason, it is recommended (but not required) for horizontally mapped classes to be declared as abstract.
This section contains the following topics that discuss the inheritance mapping feature of the Telerik Data Access Fluent Mapping API: