БД для системы комментирования

Question

Я хочу создать двухуровневую систему сообщений о статусе.Какой лучший способ создания таблиц?

Область действия:

1. Пользователь устанавливает сообщение о состоянии
2. Пользователи Ответ на сообщение о состоянии

это изображение, показывающее это

Таблицы, которые я создал

пользователей (id, name ....)status_messages (id, message, time, user_id) status_message_replies (id, message, time, status_message_id, user_d)

Некоторые предположили, что это можно сделать в формате одной таблицы

status_messages (id, pid, message, time, user_id)

, где pid = selfId или ParentId статуса.

Я хочу знать, какой метод создания системы является лучшим?

Answer 1

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

Множество исходных сообщений можно найти, где pid = selfid, а ответы - где pid <> selfid. Если важно иметь возможность видеть исходные и ответные сообщения отдельно (без знания механизма хранения), вы можете инкапсулировать вышеуказанные условия в два ПРОСМОТРА: Оригинальные сообщения и ответы.

Если оригиналы и ответы имеют разные атрибуты (например, если вы хотите, чтобы оригинал разрешал ссылки на URL-адреса, фотографии и т. Д.), Вы можете рассмотреть возможность использования двух отдельных таблиц. Но даже там, я бы, вероятно, поспорил бы с одной структурой таблицы с отдельной таблицей расширения для дополнительных атрибутов. Это означает, что вам не нужно хранить часто пустые столбцы для тех исходных сообщений, которые не используют расширенные атрибуты, и позже вы можете легко добавить расширенные атрибуты и в ответные сообщения (при желании).

Answer 2

Классическое отношение IS-A: каждый ответ - это сообщение с дополнительным атрибутом (сообщение, на которое он отвечает).Это, вероятно, не лучший способ его моделирования.Вы рискуете написать много запросов UNION к этим двум таблицам.

Альтернативы:

• только одна таблица: status_messages (id, message, time, status_message_id, user_id) и разрешение status_message_id для NULL
• используйте HAS-A: одну таблицу status_messages (id, message, time, user_id) и одну таблицу replies (reply_id, replies_to_id

У первого недостаток в том, что работать с NULL сложно в SQL.Последнее потребует объединений, когда вы хотите запросить ответы конкретно.

Кстати, гораздо понятнее (IMO) называть столбцы после отношения, которое они обозначают, а не таблицы, к которой они относятся.