База данных Консультант по разработке решений

Question

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

A) Поскольку поля в БД для статей и блог являются одинаковым (например: название, Основное содержание) ожидать «Тип» (сообщения или полные статьи), я думал, что будет хороший дизайном решение иметь одну таблицу «Страницы» и сопоставить таблицу Look Up для «Тип».

• Это хорошие дизайнерские решения?
• Где разместить кластерный индекс для повышения производительности?

B) Статьи и записи в блогах могут иметь свойство «Верхняя статья» или «Выбор редактора». Я решил управлять этим свойством, добавив поле в таблицу «Страницы», например «IsTop Article» и «IsEditorChoice».

• Это хорошие дизайнерские решения?
• Может ли смысл использовать отдельную таблицу и связать FK для этих полей?

Answer 1

При проектировании базы данных определите, какие элементы данных (статьи, сообщения) и какие атрибуты элементов данных (тип, верхняя статья, выбор редактора).

Атрибуты, которые всегда будут присутствовать, например «тип», могут иметь свой столбец в таблице элементов данных, так как они всегда будут заполнены. Если элементы данных могут иметь более одного типа, то вам нужно отделить «тип» от отдельной таблицы (отношение «один к большому»).

Атрибуты, такие как верхняя статья и выбор редактора, не связаны с каждым элементом данных, поэтому они должны быть в отдельной таблице. Думайте о них больше как о категориях. Имея их в отдельной таблице, вместо столбца вы можете легко добавить «категории» без изменения структуры таблицы.

Я хотел бы предложить базовую структуру, как это:

content 
content_categories (relation between content and categories) 
categories 
content_type (relation between content and type) 
types 

Answer 2

Если вам нужно изменить любой тип (должности или статьи), вы получите множество нулевых полей.

В целом, если предприятие стоит само по себе, оно заслуживает собственной таблицы базы данных.

Что касается кластерного индекса - это обычно помещается в поле id. Начните искать добавления некластеризованных индексов в полях, которые используются в статьях select и where, но не переборщите, поскольку слишком много индексов могут повредить производительность вставки.

Что касается полей «Top Article» и «Editor Choice» - это зависит от того, как вы собираетесь использовать их и как они относятся к сообщениям и статьям.