Преимущества моделирования данных в одной таблице в сравнении с использованием двух таблиц

Question

Предполагая, что вы моделирования Q & базы данных с помощью MySQL, я знаю два способа приблизиться к модели архитектуры:

1. Создание одной таблицы для вопросов и ответов с «typeId»
2. Создайте две отдельные таблицы; один для вопросов и один для ответов

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

Моих собственные наблюдения:

1. подхода 2 является более нормированным
2. подход 2 требует два «комментариев» таблицы для Вопросов и Ответов-то или одной таблицы с композитными первичными ключами; (& одинаковые идентификаторы мая Q это в)
3. подход 1 может стать очень сложным с собой присоединяется и так далее

Answer 1

Специфики конструкции действительно зависит от ваших потребностей и того, что вы хотите достичь и как огромной база данных будут.

1-таблица подход: Вы можете быть в состоянии использовать одну таблицу в том случае, когда вы только предоставить/разрешить один ответ на каждый вопрос (меню FAQ), где вы бы только id,question,answer поля и вопросы не добавляется в DB до тех пор, пока не будет дан ответ, или не обновите строку, когда будет доступен ответ.

2-table approch: Как только может возникнуть более одного ответа/комментария к вопросу. Я мог бы выбрать модель, немного отличающуюся от @ Spredzy, поскольку я просто включил бы все, как «электронные письма»: message_id, in_reply_to, timestamp, text для простоты. Эта простота не позволит вам помечать конкретные (ответы VS-комментариев, если только один ответ и in_reply_to ответа не становятся комментариями, как на SO). Вопросы касаются in_reply_to IS NULL.

3/более стол подход: Если вы действительно хотите, выступления с длиной FIXED-ROW на главном столе и не нужно показывать отрывок из вопросов и ответов, но только хотите знать номера. Вы разделили бы текст, любые вложения и т. Д. Или просто потому, что вы хотели бы избежать самостоятельного присоединения, как было предложено @orangepips: « Наконец, сам присоединяется к сосу и представляет отличный способ убить производительность.») и иметь отдельный столы для всего.

Answer 2

модели это как две таблицы. Вопросы могут иметь более одного ответа. Создайте отдельные таблицы комментариев для вопросов и ответов; скорее всего, использовать случай, я полагаю, не видит смешения данных комментариев в одном заявлении DML.

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

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

Answer 3

Я бы создать 2 таблицы:

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

Другая таблица будет довольно простой таблицы: Тип

type_id type_desc 
xxx-x-xx question 
xxx-x-xx answer 
xxx-x-xx comment 

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

Наконец, технически говоря, чтобы получить весь вопрос или весь ответ на один вопрос, это просто простое соединение.

Надеется, что это может помочь,

Answer 4

Одна таблица на тип данных. Если вопросы и ответы идентичны (как объекты в ООП), достаточно одной таблицы. Если нет, то нет.

Одна таблица комментариев с составными PK является правильной, так как комментарии по-прежнему относятся к одному типу объекта: Комментарий. Тот факт, что они могут ссылаться как на Q, так и на A, не влияет на это.