Как лучше спроектировать базу данных (mysql)?

Question

[Дмитрий Спиридонов]

Доброго времени суток!

Имеется футбольный сайт fc-dnipro.com.ua. Сейчас переписываем его с использованием базы данных.

На сайте есть несколько категорий статей: новости, матчи, интервью, кубки и т.д. Большинство статей, но не все, должны выводиться на ленту новостей.

Статьи из разных категорий имеют разную структуру: новости - заголовок и текст новости; интервью - плюс интервьюируемый; матчи - "перед матчем", "протокол", "отчёт" и т.д.

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

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

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

Answer 1

[Kerman]

Я бы для каждого раздела создавал свою табличку. Так проще потом информацию вносить.
А для того, чтобы выбирать на главную новости можно создать VIEW, которая объединяет все объекты из всех таблиц в одну с помощью UNION.

Если точнее, для сводной таблицы можно вынести только несколько параметров:
ID объекта, раздел, дата (чтобы сортировать). После выборки для показа на главной уже можно запросить нужные поля из профильной таблицы.

Comments

[Дмитрий Спиридонов]

Спасибо! Буду делать по вашему варианту.

Answer 2

[AlexChebanenko]

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

Например, можно сделать такие таблицы: articles (статьи), properties (дополнительные свойства статьи, какими они могут быть) и properties_values (значения дополнительных свойств, имеет структуру id_статьи - id_свойства - value).

Похожий подход используется в CMS, которой я пользуюсь.

Answer 3

[Rsa97]

Обычно сначала приводят базу к третьей нормальной форме (1NF, 2NF, 3NF) а затем частично денормализуют если есть проблемы с производительностью.

Answer 4

[afiskon]

Есть несколько способов. Например, создаете таблицу с общими полями для всех типов статей, типа articles: id, slug, title, desc, type. Затем для каждого конкретного типа - таблицу с характерными для данного типа полями, article_types: id, field1, field2, ...

Или делаете полную денормализацию - в одной таблице все возможные поля, которые в зависимости от типа будут или не будут NULL.

А можно вообще сериализовывать дополнительные поля в JSON и хранить его в специальном поле.