hasMany против структуры "hasMany through" БД для приложения с многопоточными сообщениями

Question

Я делаю веб-приложение PHP / MySQL с базовыми функциями обмена сообщениями. Два пользователя будут иметь возможность вести "беседу", которая будет содержать серию сообщений.

Вот примерные отношения, которые я задумал:

Пользователь > многие ко многим > Диалог

Разговор > многие ко многим > Пользователь И один ко многим > Сообщения

Сообщение > принадлежит-пользователю > Беседы (также может при желании принадлежать пользователю)

Для этого мне понадобятся следующие таблицы / поля:

пользователей

• Я БЫ
• ...
• [много других полей, которые не имеют значения]
• ...

Диалоги

• Я БЫ

ConversationsUsers

• Идентификатор пользователя
• conversation_id

Сообщения

• Я БЫ
• Идентификатор пользователя
• conversation_id
• текст

Как видите, я рассматриваю таблицу присоединения ConversationsUsers для управления отношениями "многие ко многим" между пользователями и беседами.

Мои вопросы:

Я пытаюсь выяснить, является ли это лучшим способом сделать это, и в настоящее время меня беспокоят две вещи:

1. Кажется неэффективным / неудобным для таблицы бесед иметь только один ID поле, работа которого состоит в том, чтобы просто связывать сообщения. Есть ли более элегантный способ сделать это?

2. Мне нужно хранить некоторые пользовательские данные о разговоре, такие как is_archived, В моем плане выше это невозможно, если я не добавлю эти поля в таблицу соединений. Я думаю, это известно как hasMany через CakePHP, который я использую (v2.6.x). Я не могу придумать, как этого избежать, но я бы хотел, если это возможно, потому что я нашел, что эти отношения трудно поддерживать в прошлом.

Любые другие мысли / отзывы о моем подходе приветствуются.

Answer 1

Привет смотрите ниже Staructure:

Users
    ID
    ...
    [lots of other fields that don't matter]
    ...

Messages

    ID
    unique_conversation_id (put timestamp in this field and use it like unique conversation id and do proper indexing)
    user_id
    text

Вы можете легко удалить из этих буксирных столов разговоры и разговоры пользователей.

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