Варианты проектирования БД

Если я правильно понял мысль, то это просто 2 разные нормальные формы таблиц.

Если мы говорим о реляционных БД, то первый вариант имеет очень ограниченное применение. Да это универсально, но за универсальность надо платить, в данном случае, производительностью.

Если хочется объектную бд, то нужно пользоваться хотя бы ORDMS (объектно-реляционная) PostgreSQL...

В первом случае вы, как мне кажется, описываете так называемую EAV модель, или модель Тенцера. Недостатки очевидны - медленные INSERT, UPDATE, DELETE. Необходимость реализовывать самому проверку связей между объектами, интерфейс по управлению свойствами объектов, типов, и т.д. Плюсов тоже не мало, это почти(!) универсально, но не так производительно, как во втором случае. Мне кажется тут надо смотреть, для чего конкретно разрабатывается БД.

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

А затем появятся объекты, которые как и туда и сюда подходят. Грубо говоря были Новости и Статьи, к ним добавили Анонсы - куда их - в отдельную таблицу?
Затем придут теги - и все сущности придется как-то перевязывать между собой, то есть к каждой таблице сущностей добавится еще таблица-связка с тегами.

Первый вариант похож на систему, расчитанную под будующую (считаем неизвестную на момент разработки) сильную кастомизацию. Один из таких известнейших продуктов - 1С.

http://www.oracle.com/global/ru/oramag/august2004/russia_gen_abramov.htm

В статье дано описание Remedy, это не суть важно, легко можно подставить туда и "пункт 1".

Я знаю третий. Как только кармы хватит напишу статью по этому поводу.

1 вариант использутся при гибкой по своей природе структуре таблиц
За второй вариант вас зато никогда не побьют последующие разработчики

Можно предложить еще "третий" вариант: настройщик описывает сущности и связи в какой-либо нотации, а программа затем "умно" генерирует объекты БД (таблицы, хранимки...)по второму варианту.
Выйдет очередной конструктор а-ля 1С :)

Все это объединено дисциплиной ORM (Object-Relational Mapping) и хорошо описано на разных ресурсах. Способов представления объектов немного больше чем 2. Вот, например, есть такая статья: http://www.agiledata.org/essays/mappingObjects.html

На мой взгляд, первый вариант — типичная ошибка проектировщика, стремящегося к универсальности. Сколько я видел обобщенных систем в своей сфере (автоматизация для малого и среднего бизнеса), это всегда было в десять раз больше работы и в десять раз более сложный код, при практически идентичном результате. Это не решение, а перекладывание проблемы в другое место; как в RFC 1925:

(6) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it.

(6a) (corollary). It is always possible to add another level of indirection.

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

Правильнее второй метод, только не в точности таком виде. Каждый тип данных может хранится в отдельной таблице, но ведь он может и «включать в себя» другие типы данных. Если есть статьи, посты в блоге, новости и у них есть общие свойства, например, ко всем можно добавлять комментарии, то можно вынести это общее в отдельную таблицу, скажем, «сообщений», и добавлять комментарии к каждому сообщению. В данном случае «сообщение» получается абстрактным типом, которой сам по себе не используется, но входит в состав каждой статьи, поста и новости; они от него как бы «наследуют», хотя наследование термин не очень удачный. Предположим, что за новости не голосуют, а за статьи и посты можно; в таком случае статьи и посты будут ссылаться на хранящийся отдельно «рейтинг», и голоса будут добавляться к рейтингу, а не к статьям. В таком случае, чтобы начать голосовать за новости, достаточно будет добавить в таблицу ссылку на рейтинг. И т. д.

Для хранение объектов с похожей структурой годится наследование, в котором основная таблица
содержит общие для всех атрибуты, такие как id, pub_date, mod_date, author_id ...., а
остальные таблица наследуя ее, добавляют свои атрибуты. При этом можно использовать поиск как
по отдельным таблицам, так и по всем (спрашивая мастер таблицу). В PostgreSQL это реализуется
весьма просто. Есть еще способ в PostgreSQL - иметь одну таблицу с общими атрибутами, а всю
специфику вынести в отдельное поле типа перлового хэша.

Для хранения объектов с множеством (от одного до сотни и далее) свойств еще выгодно использовать мета-таблицы.

Например есть сущность User, есть сущности UserGroup, UserAccess etc. В основной табллице хранится главная информация - login, password, created_at и т.д., и связи с правами и группой. В мета-таблице - UserMeta - хранятся свойства объекта в виде ключ-значение: что то вроде (id, user_id, property, value).

Тогда при выборке свойств объекта будут два запроса - первым этамом выборка информации из главной таблицы и связанных таблиц; вторым этапом выборка мета-свойств объекта.

Кто еще применяет такую же архитектуру? Знаю что в WordPress используется такая же идея (свзянность между posts и posts_meta).

Работали над проектом автоматизации финансового блока компании.
Архитектором выбрал первый вариант, в связи с планировавшейся большой универсальностью и подключением большого числа модулей других подразделений компании.
В итоге все это вылилось в огромный геморрой при работе с данными и пришлось все упрощать и отпиливать напильником в сторону второго варианта.

Такой вариант хорош если:
1) объектов много и взаимосвязи между ними также должны быть динамическими;
2) типы объектов должны создаваться не программистом, а неким дизайнером или внедренцем;
3) структура тщательно продумана архитектором с опытом работы с такими системами;

Такая система очень хорошо масштабируется в обоих направлениях (репликация, партионирование по датам, кэширование), сравнительно легко апгрейдится и дорабатывается.

Но есть и очевидные минусы. Сильно бОльшая сложность разработки и тестирования, большое (иногда огромное) количество бизнес логики в БД (триггеры, процедуры, констрейнты и прочие) и часто меньшую скорость работы за счет универсальности.

Хочу прокомментировать первый вариант - сейчас на работе с ним приходиться иметь дело...

Описание данной схемы неполно... В нашем случае ObjectsFields является не отдельной таблицей, а целым набором таблиц, для разных типов данных своя таблица. Т.е. существуют таблицы ObjectFieldsVarchar, ObjectFieldsDate, ObjectFieldsBlob и так далее... Понятно, что можно сделать одну таблицу ObjectsFields, в которой будут поля всех типов, но в итоге это совсем не намного изменит ситуацию - работать с этой пачкой сложно.

Присоединюсь ко всем здесь высказывавшимся - работать с этой пачкой говна очень сложно. Либо полностью через хранимые процедуры (которые возвращают тебе строку с полями, которые ты запросил), либо приходится делать УЖАСНЫЕ извращения на клиенте. В частности ужасной ужастностью здесь является известная N+1 проблема, из-за которой динамическая lazy-линковка практически невозможно.

1. Это архитектурный паттерн БД EAV (Entity-Attributes-Values).
2. Это архитектурный паттерн БД Entities and External Domains (название моё, модель по-умолчанию для большинства учебных и малых схем).

Есть ещё:
3. Core Entities & Hiers (Ключевые сущности и наследники, очень мне нравится в последнее время).
4. DW (Facts & Dimensions) — классика аналитических систем.
5. Регистры — хорошее решение для учётных систем.

Кое-какие детали есть здесь: http://DatabaseDesignPatterns.org/index.…

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