Q & A и блог-сайт - держать за одним столом или разделить на 2 или 3 стола?

Question

Работа над идеей для сайта Вопрос / Ответ / Блог. Для содержания каждого из них я могу хранить их все в одной таблице с некоторыми столбцами, применяющими или не применяющими к каждому из этих различных типов столбец типа, чтобы различать каждый - ИЛИ, я могу разделить их на две таблицы. Вопрос / Блог, и Ответить (или другое комбинированное) или в 3 таблицы, по одной для каждого типа.

В одной идее таблицы столбцы будут выглядеть следующим образом: id / heading / detail / type / qid

• тип столбца будет различать каждый из них как «вопрос» / «блог» / «ответ»

• qid будет ссылаться на идентификатор вопроса для ответа

ВОПРОС: используется заголовок, деталь, тип

БЛОГ: использует заголовок, деталь, тип (qid соответствует вопросу, если он назначен как ответ, но не типично)

ОТВЕТ: использует detail, type, qid (qid соответствует id вопроса, не использует столбец заголовка)

Может существовать еще один или два столбца (не показаны), которые могут относиться к одному типу, а не к другому.

Я думаю, что хранить все на Таблица может упростить запросы, если между ними есть взаимосвязь, но таблица становится намного больше быстрее ... Какой хороший подход к такой структуре базы данных / таблицы с учетом того, что это сообщество может со временем стать довольно большим (10 КБ для 100K активных пользователей)?

Некоторые типичные отношения:

A будет относиться к Q как к ответу (ответам) на Q. Может быть несколько ответов на Q. Q, A, Все B будут перечислены в одном и том же окне с флажками выбора, чтобы показать / скрыть Q & A или B или ОБА. Ответы на Q могут быть связаны с A или B (пользователи могут назначить блог в качестве ответа, но ожидают, что он будет реже). Количество A значительно перевесит их все, с Q следующим и B наименьшим.

Я склоняюсь к одному столу для Q / B и другому столу для A - НО у меня нет хорошего четкого обоснования для этого. (У вас недостаточно опыта, чтобы рассматривать вещи с точки зрения масштабируемости, ремонтопригодности, нормальности, надежности, ясности и т. Д. c. И будущего влияния.) Может быть, приоритет будет масштабируемость и ремонтопригодность?

Спасибо за ваши мысли !

Answer 1

Я думаю, что хранение всего в одной таблице может упростить запросы там, где между ними есть связь, но таблица становится намного больше быстрее ... Что является хорошим подходом к созданию базы данных / таблицы, подобной этой, с можно ожидать, что со временем это сообщество может стать довольно большим (от 10 до 100 тысяч активных пользователей)?

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

Не следует связывать дизайн базовой таблицы с настройкой производительности и оптимизацией или масштабируемостью в этом отношении.

Мое обоснованное предположение

Вопрос и блог по сути являются подтипами одного и того же объекта. Я бы использовал ту же таблицу, возможно, назвав ее «контент» или «элемент». Используйте столбец tinyint или char [1], чтобы указать, является ли это блогом или ответом.

Столбцы "type Speci c" могут требовать таблиц подтипов с определяющим отношением (разделяя ключ таблицы элементов), что позволит вам присоединиться и получить эти атрибуты Speci c типа, если вы нужно их. Это сложнее для кода, и если у вас есть только несколько из этих атрибутов, было бы проще и, вероятно, не так много, просто иметь их в таблице элементов. Например, неиспользуемые столбцы varchar () не имеют реальной стоимости, если в строке их нет. Эти столбцы нельзя объявлять как отличные от NULL , поскольку они являются необязательными.

user
----
id (pk) unsigned integer
username varchar(100)
etc..

item
----
id (pk) unsigned integer
user_id (fk) (author of question/blog post)
type not null unsigned tinyint (1 = "blog", 2="question")
title varchar(100)
detail text
created_at timestamp

answer
------
id (pk) unsigned integer
user_id (fk) (stores user key)
item_id (fk) (stores parent item key)
details text
created_at timestamp

Это базовый c каркас, который большинство систем этого типа будет иметь в простейшей форме. Он основан на простом отношении «Один ко многим» (один элемент может иметь много ответов). Если учесть это, ответ на самом деле не отличается от комментария.