В тему наследования:

Раз применил (больше пока потребности не возникало) следующую схему
Постановка задачи: Хранение в системе бизнес-документов одного типа, но с разными доп полями в зависимости от вида, которых изначально было порядка 7-8.
Варианты:
1. Делать отдельные таблицы для каждого - не вариант, т.к. пользователю их надо было показывать разом в виде списка.
2. Отнаследовать их друг от друга - вариант, но тогда таблица будет разрастаться дополнительными полями, что соответственно скажется на скорости + вариант не очень подходил, т.к. вид документа мог поменяться после создания самого документа
Решил сделать третий вариант:
1. Выделил поля, которые будут показаны пользователю при выводе списка документов (т.е. поля общие для всех видов), из них сделал хранимый общий класс
2. Сделал хранимый базовый класс для расширений, и ссылку из него на общий класс
3. Сделал иерархию наследования для всех видов документов с их доп полями.

В итоге получилось:
При запросе списка документов - используется легкая версия глобала данных
При запросе отдельного документа - подцепляются все нужные доп поля

Через пару недель коллеге потребовалось реализовать очень похожую задачу, в которой бизнес-документы были практически идентичными, но все же отдельными:
1. Добавили один признак в общий класс, разделяющий старые и новые документы
2. Добавили в иерархию наследования соответствующие расширения

ЗЫ обычным наследованием хранимых классов тоже пользуемся, но с осторожностью и только там, где оно действительно нужно

По теме слияния
Ради понтов это делать не стоит, т.к. в дальнейшем могут появиться новые проблемы, например, в наследовании хранимых классов при существующей базе не так тривиально перенести поле в базовый/дочерний класс или поддержка уникальности индексов.