IceJOKER, я перечитал тему два раза и так и не понял почему ты против предложения Кота Матроскина?
Есть диалоги и комнаты. Комнаты доступны всем, диалоги только избранным лицам. Ну и в чем проблема? Диалог - это та же комната, только с закрытой (может быть даже на ключ) дверью, а не открытой для всех аркой.
То есть должна быть таблица Поле type содержит значения public/privat, где public - это обычные комнаты, доступные всем, privat - диалоги тет-а-тет или группой (это если по большому счёту нет разницы между тет-а-тет и группой, то есть один пользователь пригласил другого поговорить, и пока они говорят вдвоём это тет-а-тет, а как кто-то из этих двоих захочет пригласить третьего, то после нажатия кнопки приглашения, в диалоге появился третий пользователь, то диалог автоматически станет групповым. если же существует разница между тет-а-тет и групповыми, в том что в тет-а-тет нельзя добавлять новых пользователей, а в групповой диалог можно, то конечно должно быть третье значение - group, но это честно говоря, уже мелочи реализации интерфейса и на структуре таблиц это никак не сказывается)
Понятно, что есть табличка . С этой табличкой думаю неважен тип комнаты. Можно писать всех кто зашёл в комнату, хоть в общую, хоть в диалог. Разница только в том, что добавление пользователя в общую комнату происходит в момент нажатия пользователем на название общей комнаты, а в диалог только по специальной кнопке создания диалога (пользователь, создающий диалог становится один из участников) или кнопке приглашения в диалог.
Ну и понятно табличка естественно я опустил таблицу пользователей Естественное и лежащее на поверхности решение, почему идёт отторжение этого решения не понимаю. Из-за иконок что ли? Так тут просто надо подумать какие иконки записывать. У общих комнат может своя универсальная иконка или админ в момент создания комнаты может ей иконку присваивать. У диалогов тоже всякие варианты могут быть или иконка из профиля пользователя создавшего комнату или пользователь, создающий диалог пдобно админу присваивает любую понравившуюся ему иконку. Это это логика программы. Структура БД тут вообще ни причём

IceJOKER , а вот решение с записью общих комнат в таблицу пользователей вообще непонятно. Вы, как автор данного преложения, объясните пожалуйста, как оно будет реализовано.

IceJOKERэто решение не нравится тем, что у диалогов будут иконки...т.е. - Если смотреть без комнат, то при создании нового диалога, в качестве иконки будет стоять аватар одного из участников
а какого именно участника диалога? случайным образом будете определять?

IceJOKER и не будет столбца type , т.к. эту роль на себя возьмет столбец type из таблицы users и плюс если учесть, что записи в users будет меньше чем в dialogs (т.к. в среднем хотя бы каждый второй создаст 1-2 диалога), то не лучше ли минимизировать эту таблицу ?
ну не будет столбца type в таблице диалогов, зато такой же столбец появится в users, хотя он там не нужен
IceJOKERв случае, если комната будет выступать как пользователь(с type = room) , то нужно будет следить за type при работе с пользователями.
Как в этом случае сообщения записывать будете? какой идентификатор будете записывать в поле dialog_id?