Осталось выбрать архитектуру БД

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

таким образом, очень сильно обобщая архитектуру БД:

1. Таблица Типы сущностей - Название типа сущности, Описание
2. Таблица ID объекта - ID объекта, Название, ID типа сущности из таблицы (1)
3. Множество таблиц, которые связаны с таблицей (2) отношениями один ко многих. Пример пары таблиц, описывающих Новость:

ID объекта, DISABLED, DELETED, TIME_CREATED, TIME_LASTEDIT
ID объекта, TITLE, DESCRIPTION_SHORT, DESCRIPTION, AUTHOR

Таким образом, каждый объект собирается JOINами из таблицы (2) + нескольких таблиц из (3)

Что скажете, друзья? Стоит ли подобную архитектуру использовать в проекте с относительно большим объемом (десятки млн) записей ?

Программист-Любитель" Все велосипеды уже изобретены и ждут своих седаков " (С) Форум SQL.RU

если так, то почему ваш логин программист-любитель, а не велосипедист-любитель? ;)

sppilot911,

Вы уже не первый кто пробует разрабатывать ООБД на базе реляционной
Посмотрите поиском тут на сайте по EAV - обсуждались как плюсы так и проблемы такой архитектуры

с SQL работал, с ООБД работал, EAV изучил давно, но может кто скажет, что это зря и 5-6 JOINов для больших и серьезных данных неприемлимо... честно говоря, чуток опасаюсь