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

Question

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

Область применения:

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

это изображение показывает его

Столы я создали

пользователей (номер, имя ....) status_messages (идентификатор, сообщение, время, user_id) status_message_replies (идентификатор, сообщение, время, status_message_id,) Пользователь D

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

status_messages (ID, PID, сообщение, время, user_id)

, где PID = SelfID или ParentId статуса.

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

Answer 1

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

Набор исходных сообщений может быть найден где pid = selfid и ответы, где pid <> selfid. Если важно иметь возможность видеть оригинальные и ответные сообщения отдельно (без знания механизма хранения), вы можете инкапсулировать вышеуказанные условия в два вида VIEW: OriginalMessages и Responses.

Если оригиналы и ответы имеют разные атрибуты (например, если вы хотите, чтобы оригинал разрешал ссылки на 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. Последнее потребует объединения, если вы хотите запросить ответы конкретно.

BTW это намного яснее (IMO), чтобы называть столбцы после отношения, за которое они стоят, а не таблицы, на которую они ссылаются.