Всем здрасте. Прошу не судить строго, это моё первое сообщение на форуме :)
Сразу хочу сказать, что для понимания моего вопроса нужно знать, что такое Single/Class/Concrete Table Inheritance, EAV (Entity-Attribute-Value) и Serialized LOB (Large object). Таким образом, вопрос мой связан с сопоставлением классам приложения таблиц БД (не очень оригинальная проблема, но всё же...).

Возможно ли сосуществование сразу нескольких паттернов при проектировании, скажем, каталога товаров? Я знаю, что невозможного нет, но будет ли это разумным решением и не приведет ли к излишней запутанности БД?

Скажем, я хочу сделать единую таблицу товаров, содержащую общие поля (код товара, название, описание, цена). В каталоге есть такие категории товаров, как автомобили и запчасти. Автомобили могут быть легковые и грузовые. У всех автомобилей есть общие характеристики (для них создаем еще одну таблицу для хранения только этих характеристик), но у легковых дополнительно задается число мест, а у грузовых - грузоподъемность. Я решаю хранить эту информацию в той же таблице всех автомобилей. Таким образом, я совмещаю сразу два паттерна: Class Table Inheritance (CTI) и Single Table Inheritance (STI).

Запчасти тоже бывают разные, и я могу создать под каждый тип отдельную таблицу, получив еще один CTI. А могу еще и некоторые характеристики деталей запихать в одно большое поле (получив Serialized LOB), если вдруг выяснится, что поиск по этим характеристикам никому не нужен будет.

В общем, путём скрупулезного аналеза предметной области, у меня получится вот такой монстр. Может ли это дать какие-то преимущества и вообще, хорош ли сам паттерн Class Table Inheritance? Ведь он связан с большим числом JOIN-ов при увеличении вложенности. В тоже время не всегда разумно запихивать все поля в одну большую таблицу.

Также я хочу сделать некий инструментарий, который будет позволять иметь в приложении обычную иерархию классов, с которой очень легко работать, а в базе данных иметь нечто вроде выше описанного (по сути, скрыть от обычного программиста все сложности реализации маппинга между классами и таблицами и дать ему спокойно работать над своими задачами).
Может ли такое комбинирование иметь реальное применение? Воспользовались бы вы такой моделью в своем приложении или сделали бы по-старинке либо одну большую таблицу, либо кучу отдельных и не стали бы "мешать мух с котлетами"?

P.S. Прошу простить за некую сумбурность мыслей, но у меня сейчас самые что ни на есть творческие муки, и я пытаюсь найти правильное решение (хотя и допускаю, что в данном вопросе единственно правильного может и не существовать) :)

guest_20040621 ,
Не надо привязываться к конкретной базе, терминологии, автору. Также я не пытаюсь сделать универсальную базу. Наоборот, я не хочу пользоваться такими вещами, как EAV, когда существуют альтернативные пути. Если в приложении есть иерархия классов, то кто-то создает одну большую таблицу с сотней полей, кто-то для каждого класса создает отдельную таблицу, кто-то пихает все атрибуты в одно поле таблицы. Вопрос в том, будет ли иметь смысл комбинирование этих подходов.

В любом случае для каждого выбранного варианта мне в своем приложении придется писать программный код для сохранения объектов в реляционной бд и получения их обратно. Так почему бы не предусмотреть ситуацию, когда эти подходы могут использоваться совместно?