В паралельном топике услышал критику выбранной архитектруры БД. Хочется подробнее оценить плюсы и минусы, и услышать мнения. Заодно, уверен что подобная архитектура уже была придумана ранее. Если это так, дайте ссылку на соответствующи паттерн или статью.

Итак задача данной архитектруры, позволить произвольным образом связывать обьекты. Для чего это нужно? Разрабатывается социальная сеть. Каждый пользователь такой сети может быть владельцем множество различных обьектов, таких как, фото, фидео, музыка, блоги, чаты, форумы, гоставые книги. Этот пользователь может комментировать, писать блоги в сооществах. Загружать фото в сообщества или присоеденять их к комментариеям. Сам пользователь может состоять в различных сообществах, быть в фаваритах у других пользователей, или в контакт листах. Налицо множество сложных связей. Причем эти связи и необходимость в них может менятся. Например может возникнуть необходимость что бы один обьект (например видео ролик) принадлежал разным пользователям одновременно, или например блоги могли быть связаны с фото, и наоборот. Вобщем класическая реляционная модель пораждает множество сложных связей, лишних таблиц и полей. Поэтому было выбрано более простое и элегантное решение.

Каждый обьект в БД, это поле таблицы. Для каждого типа объектов, своя отдельная таблица. Разница только в том, что каждая запись имеет лишь примари кей, и нет никаких внешних ключей. Связь осуществляется через таблицу с именем GUID, состоящею их четырех полей. 2 поля, это ID свзяанных обьектов, то есть внешние ключи. Класическая схема - много-ко-многим. Только ID не может уникально идентифицировать объект в пределах БД, ведь в разных таблицах ID может повторяться. Поэтому введено понятие типа объекта. И пара ID-TYPE являются уникальным идентификатором объекта в пределах всей БД. Поэтому таблица связей GUID состоит из 4 полей, первые 2, как я сказал выше, это ID связанных объектов, а остальные 2 это их типы. Зная ID и тип объекта, можно выбрать все связанные с ним обьекты, как все, так и конкретного типа.

Это позволяет строить самые причудливые связи, и очень гибко реагировать на изменение бизнес требований к системе.

Какие недостатки я вижу сразу. Впервую очередь это огромная таблица GUID. Ведь мин количество записей в ней равно количеству записей во всех таблицах БД. И это только минимальное, ведь обьект может быть связан сразу с несколькими другими обьектами.
Второе это более тяжелые запросы. Если связь один-ко-многим то выборка будет лишь по внешнему ключу, а в моей модели внешнего ключа нет, и приходится джойнить таблицу GUID.

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

Итак, интересно ваше мнение.

drevИМХО, система рухнет в тот момент, когда у Вас появиться необходимость указать параметры связи.

Например, связь человека с его фотографией не имеет параметров, а свызь людей, котрые оценивали его фото имеет пара,етры оценка и время.

Пример взят из одноклассников:)Создается таблица rating с полями value и rating_date. При голосовании:

RatingComponent rating = new RatingComponent();
rating.setField(<размер оценки>);
rating.setField(<дата>);
ratng.save();

PhotoComponent photo = new PhotoComponent(<id фото>);
photo.addChild(rating);

Ничего не рушится.

Боевая система появится примерно через 2 недели. Сейчас уже есть пару простых ресурсов на основе этой схемы. Работают отлично.

AlexTheRavenIMHO Вам нужно хорошенько проанализировать задачу и вместо того, чтобы изобретать EAV-подобный велосипед, сделать нормальную схему БД -
Никак не пойму чем данная схема похожа на EAV
AlexTheRavenвозможно, с тысячей таблиц, но вполне конкретных.
В данной схеме все таблицы вполне конкретны. Только в них нет внешних ключей.
AlexTheRavenВыделять сущности всё равно прийдётсяони итак выделены. каждая сущность - отдельная таблица такие как PHOTOS, COMMENTS, ALBUMS, MESSAGES и тд. AlexTheRaven, но при укладывании их не в обычные таблицы РМД, а в какие-то странные поля
какие поля?
AlexTheRavenВашего велосипеда, эффективность с большой вероятностью будет очень низкой (огромные таблицы, "самообъединения" и т.д.), а сложность отладки - непомерно большой.
насчет производительности да, согласен. отладка не отличается от обычной реализации AlexTheRaven
RVK61<...>Вобщем класическая реляционная модель пораждает множество сложных связей, лишних таблиц и полей.<...>
IMHO высказывание в стиле "ниасилил". При правильном проектировании ЛИШНЕГО ничего нет. Да, сложно, да, работы много, вникать нужно и книжки читать. А Вы как хотели?
У меня опыт проектирования БД более 5 лет. Хотя читать никогда не вредно ;)

RVK61Каждый обьект в БД, это поле таблицы

Ой, конечно же не поле а запись! Очепятка...

AnddrosФактически любое чтение и любая запись в базу будет затрагивать эту таблицу. Погрязнете в блокировках. То, что годится для однопользовательского режима, далеко не всегда приемлимо для многопользовательских систем. А тут социальная сеть ... На что расчитываете? Сотни? Тысячи? Сотни тысяч пользователей? И прикиньте, сколько запросов будет сыпаться в секунду к одной несчастной таблице. Бедное железо...Может я ошибаюсь, но Оракл блокирует на уровне записи, то есть обычно блокировки не мешают чтению таблиц. Тем более что на таблице GUID запросов UPDATE не планируется. Еще я слышал что блокировки в Оракл это не дефицитный ресурс, в отличии от многих других СУБД. Если я не прав, поправьте.