Mr.Fontaine,

1. Если тет-а-тет = собеседника, если больше участников, то уже придумаю как, это уже не важно (можно по 4 аватара выводить случайно, можно просто дефолтный аватар.

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

3. Как обычно, в таком виде получается что пользователи между собой общаются, которые сами же добавились в беседу к этому пользователю(вернее к комнате). Первый пользователь написал - создалась беседа и все, когда последний вышел, то не удаляем эту беседу(запись из dialogs), т.к. т.е. у каждого users type = room будет по одной записи dialogs - раз и навсегда

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

в том то и дело, что не могу выбрать, что правильнее, а хотелось бы заложить хороший фундамент, чем потом переделывать все.
может в дальнейшем захочу сделать возможность пользователям добавлять публичные беседы, тогда они смешаются с комнатами или придется сделать такую структуру:
dialogs
id, user_id, icon, name, is_room(0,1), type(public/friends/private)

Кот Матроскин,

бэкэнд - это сервис предоставляющий базу и api для работы с ним и пока, если я не ошибаюсь, там нет условных операторов(if...)

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

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

но у ботов будет другая роль, тогда как их отличить от комнат и пользователей? сделать dialogs:
id, ...., type(room, bot), access(public/friends/private)
???

если сделать как мой вариант
users
id, ...., type(room, bot)

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

p.s. я не пишу, что мой вариант лучше, а другие хуже, я просто для себя хочу понять какой лучше и наконец остановиться на том или ином варианте

Кот Матроскин,

http://parse.com

Mr.Fontaine,

я имел в виду ботов как в Telegram, которые когда то были в icq.
Они не будут бегать и делать что-то, а будут как комнаты пылиться, пока пользователь не напишет ему, там уже начнется беседа с пользователем, где пользователь может играть в викторину и т.д.
т.е. по функционалу бот будет точно таким же как комната, но с отличием, что он будет общаться с участниками беседы(отвечать на определенные команды).

я так и писал, что можно добавить столбец type к users и присвоить значение bot(или room, дефолт - NULL , если это обычный пользователь)

Получается такая иерархия:
Пользователи<-Комнаты<-Боты

В остальном все будет как обычно, пользователи могут писать пользователям, могут писать в комнаты и ботам, т.е. dialogs так и останется:
id, user_id, icon, name, type(public...) /* где user_id - это создатель диалога(беседы) */


p.s. Ботов я для примера привел, имелось в виду, чтоб в дальнейшем была возможность расширить при необходимости, нужно как можно дальше в будущее посмотреть.

Mr.FontaineIceJOKER, ну и собери теперь все свои мысли вместе и нарисуй схему БД
То есть вы согласны с моим вариантом? Или вы хотите посмотреть на конечный результат? Или вам просто стало пофиг и решили забить? :D

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

contacrer,

решил обойтись без таблицы rooms, пока (в тестовом режиме) сделал rooms as users;
пока окончательно не решил, надеюсь на чудо :D кто знает, может схема таблицы упадет на голову..

boottyЧеловек может присоединиться в процессе разговора или выйти из разговора? Если да, то нужно ли ему показывать то, что было до его подключения? В случае постоянно работающей комнаты лог может быть огромен. А после его выхода из разговора/комнаты ему надо показывать его же историю?

Может присоединиться, выходить когда угодно, нужно показывать, сообщения беседы хранятся до тех пор, пока последний не покинет беседу, тогда беседа удалится.


p.s. если вы для себя хотите что-то узнать, то подчеркните это, а то непонятно - хотите вы помочь, или для себя что-то узнаете.
если хотите помочь - то вопросы выше не важны, мне лишь нужно наиболее грамотно отделить беседу пользователей от беседы в комнате с учетом условий, что я описал в предыдущих сообщениях

softwarerIceJOKERМожет присоединиться, выходить когда угодно, нужно показывать, сообщения беседы хранятся до тех пор, пока последний не покинет беседу, тогда беседа удалится.
Тогда вообще нет смысла использовать базу данных, особенно реляционную базу данных. РСУБД проектируются для работы с ценными данными, которые должны храниться и ни в коем случае не теряться; применять их для работы с сугубо временным малоценным мусором - стрелять из пушки по воробьям. Простенький чат-сервер с хранением в памяти будет работать в десять раз быстрее, потребляя при этом в десять раз меньше ресурсов.

Простенький чат-сервер - что вы под этим подразумеваете ? Хранить данные в течении сессии? Если да, то не подходит, т.к. данные могут храниться как 1 день, так и месяц(ровно столько, сколько пользователь посчитает нужным оставлять беседу)

boottyIceJOKERмне лишь нужно наиболее грамотно отделить беседу пользователей от беседы в комнате с учетом условий, что я описал в предыдущих сообщениях
Советовать сложно: из описания не могу понять, в чем принципиальная разница между комнатой и беседой. В том, чтобы показать пользователю только комнаты и беседы, которые он создал или в которые его пригласили? Или в том, что у беседы есть конкретный автор?

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