Table inheritance can be implemented so that we have a base table with common attributes, as well as specializations that extend that table and add their own attributes and methods. This is similar to classes, but only in concept—although the base table can have many child tables, only one physical table is created in the SQL Server. The physical table in the SQL Server contains all of the fields from the base table and its child tables.
A good candidate for this is the vehicle table, where we could have a base vehicle table and a child table for each type, such as Bike, Car, and Truck. This is suitable as long as we are sure these can be considered physical data structures, and not a categorization. For example, we can change a product from inventory to non-inventoried by changing the inventory model group, but we cannot change a vehicle from a Bike to a Car after the record has been created if we used table inheritance.
If we choose to use table inheritance, the result is a logical data structure that is represented as different tables in the Application Explorer but is physically stored as one table in the SQL Server. As far as we are concerned, though, these are different tables. This means that the user must choose the type of vehicle they are creating before filling in any data. This also means that it is difficult to retrofit if data has been created. Once we have started to use table inheritance, we can't remove it later.
In our case, we will alter ConVMSVehicleTable in order to use inheritance.