tangueros Предполагается, что данных в основной таблице будет много Вариант 2 однозначно.
EAV ф топку. XML только если данные ВСЕГДА будут обрабатываться одним куском, но обычно (по мере развития системы) данные начинают представлять собственную ценность и все опять сводится к варианту 2. Произойдет ли это при вашей жизни или нет - решать вам.
По минусам
tangueros не нравится идея менять схему БД, каждый раз, когда добавляется новая группа свойствА программу менять типа нравится. Новая функциональность - новая программа - новая база
tangueros к тому же количество джойнов в таком случае может вырасти до слишком большого размераНа то он и сервер чтобы джойнить. Это его работа. В худшем случае подхинтите запросы.
tangueros Вопрос возник в связи с необходимостью реализовать иерархию наследования сущностей в БД оптимальным образом.А вот с этого места поподробнее в терминах - вставляем, ищем, обновляем, удаляем.

tangueros Не совсем понятно, что значит в терминах " вставляем, ищем, обновляем, удаляем"То что для базы данных все ваши объекты - ценные бумаги суть записи, которых надо обрабатывать по типу CRUD. И делать это можно по-разному смещая акценты в зависимости от нужд приложения (типа можно подождать со вставкой за счет быстрого чтения по определенным критериям или обновлений/удалений не будет по определению поэтому просадка производительности этой операции никого не трогает).
tangueros Типов ц/б - много, поэтому заранее заводить нужное количество полей не удобно (хотя, в принципе, можно, но уж будет криво)Вот интересно, заведение дополнительного свойства, отображение его на форме, редактирование и т.п. это типа не криво. А заведение специального поля под дополнительное свойство это уже не удобно. То есть вы базу данных рассматриваете как ящик куда можно свалить все со стола как попало, зато быстро и стол чистый. А то что доставать будем долго так это база данных виновата - тормозит, надо другую брать, авось будет быстрее, ага и приложение делать независимое от базы.
tangueros Нужно грамотно реализовать наследование.Поищите по форуму на предмет хранения людей, контрагентов, легковых/грузовых машин. Способов несколько и хранение предков в одной таблице и и доп.свойств в разных таблицах связанных ссылками с главной, и отдельные таблицы с одинаковыми полями, и одна большая таблица со всеми полями из которых заполнены только нужные. Какой именно способ - выбирать вам в зависимости от нужд приложения, а не соответствия принципам ООП.
Просто помните, что за любую гибкость, как правило приходится платить .