Лучшее решение для реляционного дизайна db с различными типами контента

Question

Редактировать: заголовок довольно широкий. Было бы более точным: «Лучшее решение для реляционного дизайна db, где пользователи могут размещать контент, а доступные поля будут варьироваться в зависимости от типа контента».

Я работаю на веб-сайте, где пользователи могут публиковать различные типы контента. Все сообщения имеют текст и значение feed_id, относящее его к другому (много сообщений в один канал). Основываясь на идее, что некоторые должности будут содержать только текст, что было бы лучшим решением?

Идеи Я думал так далеко:

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

Задача: Как запросить текстовые сообщения?

• Добавить таблицу для каждого типа, включая текстовые сообщения.

Проблема: не кажется очень эффективной. Для каждого сообщения, найденного в text_posts, сообщение снова должно быть найдено в сообщениях, чтобы получить текстовое поле. Опять же, это уже имело место со специальными типами, такими как картинки. Есть ли способ сделать это с помощью JOIN?

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

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

• поле, представляющее типа поста

минусы: правила должны поддерживаться приложением (чувствительность к регистру, сообщения должны иметь только действительный тип), сложнее запрос Pro: это поля могут также представлять разные представления для аналогичного контента (т. е. я мог бы сделать значение для post_type, называемого «blog_entry», которое точно такое же, как текстовое сообщение, но приложение показывает контент по-разному). У этого pro есть немного запаха кода, хотя ...

Также, если это имеет значение, мое приложение написано на PHP.

Edit: Это кажется, что мое первое решение, «Добавить таблицу для каждого специального типа, который относится к столбу, оставляя неиспользуемые сообщения на текст сообщения», будет работать нормально, если переспросила я все сообщения, как это:

SELECT posts.title, posts.text, picture_posts.id, picture_posts.src FROM posts 
LEFT JOIN picture_posts 
ON picture_posts.post_id=posts.id 
ORDER BY posts.date DESC 

, а затем некоторые псевдо-код для приложения будет выглядеть следующим образом:

print(posts.title, posts.text); 
if (picture_posts.id is not null) { 
    showPicture(picture_posts.src); 
} 

Должен ли я использовать этот дизайн?

Answer 1

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