Вам эта база для чего, чтобы была или для работы (искать, вставлять, изменять, делать отчеты...)
Если чтобы была - то вперед в EAV. (ищите здесь на форуме все по слову EAV)
Если для работы тогда метод сущность-связь (ER)
PG81Может EAV не очень подойдет, так как классов описания будет несколько милионов?Сдается мне, что вы слегка преувеличиваете. Я не могу представить себе работу с базой в миллионы связанных таблиц. С другой стороны миллионы экземпляров вполне возможны.
PG81Я думаю, попытаться сделать аналогично описанию классов в языках программирования.Плохое начало. В языках программирования во главу угла ставятся функции (код), а в БД данные.
PG81Т.е. есть класс у него базовые свойсва, а в наследуемых классах свойства присутствуют класса родителя плюс свои
На вашем месте, я бы сначала расписал все известные классы по типу ER (один класс- одна таблица) без абстрактрых и только потом вытащил повторяющиеся части в общие таблицы предки. Это не упростит, а усложнит схему, ухудшит (в лучшем случае незначительно) производительность, но облегчит понимание структуры новыми людьми и ее модификацию.
PG81Будет ли это все нормально работать на MS SQL Server 2005 А какой смысл использовать устаревшую (не 2012, не 2008R2, не 2008) версию для нового проекта? А работать будет как сделаешь, от бренда СУБД зависит мало.
PG81Какие есть еще вариантыЕсли задача не суперсекретная, то можешь выложить сюда описание поподробнее, плюс свою реализацию и мы можем накидать примерную схему, отловить грубые ошибки в реализации, подсказать возможные проблемы для негрубых ошибок и т.д.

Да видел я этого вашего Тенцера, даже реализовывал. Наряду с "универсальным" справочником (одна таблица на все справочники) это "открытие" делал, наверное, каждый. У этой схемы только одно достоинство - добавление таблицы или поля делается без DDL (уменьшение количества таблиця достоинством не считаю). А вот недостатков выше крыши (поиском по форуму они ищутся). Короче нишевое решение для всяких определяемых пользователем свойств или справочников.

Dimitry Sibiryakov А теперь перечитываем сабж и видим там те самые определяемые пользователем свойства, они же - характеристики.
Еще раз перечитал топик. ТС просит помощи в создании базы объектов. Не заметил требований максимальной кастомизации на местах а ля 1С.
Во избежании разночтений, еще раз прошу ТС дать подробности.
Кот Матроскин Главное - это базовая обработка нового типа обьектов вообще без написания какого-либо кодаТо что форму, ввода, поиска, редактирования, отчеты будет делать местный кастомизатор, а не программист, не значит "без написания какого-либо кода"
Еще раз повторю: в качестве заплатки, "сопли", нужной еще вчера, ЕАВ вполне уместен. Но делать соплю в новом проекте...

А мой опыт говорит что умение коротко, ясно, недвусмысленно, понятно всем формулировать задачу есть великий и редкий талант.
Хрустальный шар подсказывает, что перед ТС стоит задача ведения базы таки объектов, сложной со множеством характеристик.

Кот Матроскин Какую форму? какой кастомизатор? Вы вообще о чем?Данные в дополнительных полях вводить как? Проверять введеное, использовать в расчетах, фильтровать, выводить в отчетах... если это не код то что?

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

vst_guest mssqlserver умеет файловые группы. материализация вьюх "не нужен",В огороде бузина, а в Киеве дядька
всё равно производительность упирается в storage, а не в вычисления
авторнужно грамотно разнести сущности и поля сущностей базы по группам, Какие группы? У вас в пределе только ТРИ таблицы
vst_guest а группы по разным винтам,группы на SAN. Какие там винты меня не трогает.
vst_guest и будет вам щасте. никаких просадок по производительности.Для получения строки в N столбцов придется делать N сканов (по индексу) причем никаких гарантий что они лежат в одном блоке, т.о. количество логических чтений будет минимум в N раз больше. Это только для одной таблицы, а если в джойне их M? плюс никаких намеков на оптимизацию плана.

Кот Матроскин Миллион автогенеренных таблиц и пара-тройка миллионов автогенеренных хранимых процедур, как пример производительного и легко поддерживаемого проекта? В случае с EAV проект помрет раньше, ибо этот подход СЛОЖНЕЕ. Почему автогенереных, где такое требование? DDL скрипт на базу плюс патч на программу.