Что предпочтительнее, таблица-связь или несколько доп. поля?

Question

[Actor]

К примеру на хабре есть несколько типов статей (черновик, перевод, туториал).
Что предпочтительнее, добавить к таблице с статьей дополнительные поля isDraft, isTranslate... а как быть с доп полями у разных типов? К примеру автор стать которую перевели и ссылка на страницу оригинала? Добавлять translateAutor и т.п., но будет много не нужной информации..
Или дополнительную таблицу и связь сделать?
Таблица статей + таблица всвязи + таблица свойств.

Первый вариант удобен в программировании, прямой доступ к свойству на основе AR или простые прямые запросы- все счастливы...
Второй вариант сложный AR: Article->property->value, сложные джоины в прямых запросах.

Answer 1

[_ _]

Зависит от того, что вы ставите во главу угла.
Если производительность, то все равно в итоге придете к частичной денормализации.
Ваш пример с translateAuthor - если запросов к статьям очень много, то есть смысл сохранить имя автора прямо в таблице статьи, чтобы не лезть отдельным запросом за ним.
А если немного - то и хрен с ним. Чувствуете? Все от задачи зависит.
И еще есть PostgreSQL и hstore ;)

Answer 2

[rPman]

Практика показала, что в конечном счете сложные и универсальные property/value решения все равно разовьются до кеширования значений в полях рядом (совершенно нормально будет тригерами наполнять полупустые кеш-таблицы с 100500 полей).

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

Answer 3

[egor_nullptr]

Как показывает опыт при использовании реляционной БД флаги (isXYZ, etc) добавляют гораздо больше проблем, чем выгоды. Для документно-ориентированных БД такой проблемы нет. Также можно посмотреть в сторону наследования таблиц в реляционных БД (например в Postgres).

Answer 4

[Виталий Желтяков]

Если хотите понимания кода, то нормализуйте по третей форме.

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

Answer 5

[websaitdev]

К примеру на хабре есть несколько типов статей (черновик, перевод, туториал).

Если доп свойства для каждой сущности не планируется, то я бы сделал флаги. Если планируется, то выделить сущности в отдельные таблицы и связать по ключу статьи. В таблице-справочника поставить уникальный ключ на id статьи для устранения дублей.
Если критчна скорость - объединить 3 сущности-справочника в 1 таблицу с полным набором нужных типов.

Если много разных множеств и справочников - то EAV или под каждую делать свою таблицу. EAV - гибче, но при больших данных придется сделать денормализацию и/или кеширование, как писал выше rPman. В другом случае придется тратить время на описание каждой новой сущности. Если проект позволяет, то я бы выбрал именно этот вариант.

Answer 6

[sergealmazov]

Делайте таблицу-связь. Так будет более академично, правильней и можно будет потом дорабатывать.