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

Question

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

0

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

Создайте единую таблицу для вопросов и ответов с помощью "typeId"

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

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

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

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

Mohamad 29 нояб. 2010, в 02:44

Источник

0

Есть ли какой-нибудь возможный случай, когда вы бы сохранили в этой таблице какой-то другой тип (независимо от того, какой набор содержит оба вопроса и ответа)? «TypeId» звучит так, будто вы планируете расширить его, но я не уверен, как это сделать.
Ken 29 нояб. 2010, в 03:19

Теги:

mysql

database

data-modeling

4 ответа

1

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

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

Core Xii 29 нояб. 2010, в 09:22

1

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

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

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

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

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

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

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

Spredzy 29 нояб. 2010, в 05:33

1

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

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

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

orangepips 29 нояб. 2010, в 01:10

Ещё вопросы

Есть ли какой-нибудь возможный случай, когда вы бы сохранили в этой таблице какой-то другой тип (независимо от того, какой набор содержит оба вопроса и ответа)? «TypeId» звучит так, будто вы планируете расширить его, но я не уверен, как это сделать.

Danosaure · Accepted Answer · 2010-11-29T06-30-00.000Z

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

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

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

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