Как спроектировать БД для вопроса-ответа (MySql)

Question

Мне нужно спроектировать БД для форума. Я отделяю корневой пост от его подпостов по разным причинам. Мне нужно, чтобы текст, который вводит пользователь, был оптимальным для поиска, в том числе с точки зрения производительности.

Мой вопрос, должен ли я разделить каждую таблицу (корневые записи и подпосты) на две таблицы:
root-posts_meta (содержит данные, такие как идентификатор, время создания, просмотры, ....)
root-posts_data (id, title, body) индексируется с полным текстом

Та же идея с таблицей подпостов.

Спасибо.

Answer 1

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

Answer 2

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

Я бы предложил хранить эти вещи в одной таблице.

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

Answer 3

Поскольку InnoDB не поддерживает FULLTEXT, и если требуется какая-либо поддержка транзакций, то нет никакого способа обойти это разделение.
MySQL-полнотекстового

подробное объяснение: InnoDB не имеет полного текста, MyIsam не поддерживает TX. Взять к примеру ТАК. Каждый вопрос имеет количество голосов, пользователей, которые его обновляют, историю изменений (в моей системе есть много других вещей, давайте не будем вдаваться в бизнес-логику того, что я делаю). Многие из этих полей должны меняться в течение срока службы объекта в сочетании с другими изменениями в других таблицах (т.е. изменениями в рамках одной транзакции), и мне нужна полнотекстовая поддержка полей данных.

Answer 4

По сути, корневые сообщения и вложенные сообщения в основном похожи на обычные приложения форума. Если вы действительно хотите иметь некоторую специальную информацию о начале нового потока, вы можете захотеть иметь отдельную таблицу с именем thread и все сообщения, принадлежащие этому потоку, в таблице сообщений. Сами сообщения могут иметь для parent_msg_id значение null для корневых сообщений или идентификатор другого сообщения, если они являются ответами. Как это:

thread:
- thread_id
- started_ts
- author (long live redundancy!)
- other columns

message:
- message_id
- thread_id (reference to thread-thread_id)
- parent_msg_id (nullabel reference to message.message_id)
- body, author, timestamp etc

Answer 5

Когда я сделал что-то похожее, я поместил данные потоков в одну таблицу, а данные постов (включая корневые сообщения) - в другую. Прежде чем ответить на ваш вопрос, я должен спросить вас, действительно ли вам нужно разделить root и sub?

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

Answer 6

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

Answer 7

TEXT поля сохраняются вне строки в любом случае.

Разделение таблиц не улучшит ни читабельность, ни производительность ваших запросов.

Тебе лучше держать его за одним столом.

Answer 8

Разделение не повлияет на его возможность поиска или эффективность поиска. Если это ваше единственное беспокойство, вы можете также оставить каждый стол в отдельности.