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

Question

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

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

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

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

1. Подход 2 более нормализован
2. Подход 2 требует двух таблиц "комментариев" для Q и A или одной таблицы с составными PK;(Вопросы и ответы могут совпадать с идентификаторами)
3. Подход 1 может стать очень сложным с самостоятельными объединениями и т. Д.

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

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

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