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?

Когда поймёте, что комнаты и диалоги это одна и та же сущность, и при варианте
таблица dialogs
id name user_id1 'Диалог1' 2
таблица users
id name type1 'Комната' 'room'2 'Пользователь' 'user'
таблица messages
dialog_id user_id text12'мысль для комнаты'12'тема для диалога'
Вы при выборе сообщений для комнат и диалогов просто не сможете определить какое сообщение где показывать, то и придёте к варианту, о котором Вам все тут говорят

Я Вашу мысль понял. Если она Вам кажется более правильной, чем версия Кота Матроскина, то вопросов нет

IceJOKERMr.Fontaine,
2. А может в дальнейшем расширю type и добавлю "типизированных пользователей", к примеру бота

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

IceJOKER, чё-то Вы меня сосем запутали....
Конечно понятно, что у обсуждаемых ботов будет роль, отличная от молчаливых комнатных ботов.
Молчаливые боты, по Вашей же идее, создаются, чтобы постоянно сидеть в своей беседе, и так как там кто-то сидит, и беседа удаляться не будет никогда, превращаясь постепенно в комнату, обросшую пылью.
У обсуждаемых же ботов будет роль как можно более походить на пользователей: бегать по имеющимся комнатам, создавать свои беседы, добиваться приглашения в какую-то чужую беседу и писать, писать, писать....
Это два совершенно разных типа ботов. Только вот зачем их пихать в таблицу dialogs ????
Создаётся запись в таблице users с типом 'bot' а дальше просто автоматизировать действия пользователя, но никаких дополнительных требований к структуре БД для бота не требуется.

IceJOKER, ну и собери теперь все свои мысли вместе и нарисуй схему БД