Здравствуйте.

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

Не создавать же десятки таблиц, для разного рода чатов.
Таблица одна, в которой нужен номер комнаты.
Проблема кроется в номере комнаты. Числовая комната не получается, ибо теоретически вариантов больше, чем возможных числовых комбинаций. В добавок, если суммировать id пользователей, вариантов повторений больше, чем хотелось бы.
В итоге номер комнаты может получится только текстовый, где либо хэш, либо что то типа: 144287_376252.

И вот что хочется от вас узнать:
1. Если чат на базе данных, как организовать номер комнаты? Или какой подход для номеров комнат осуществить?
2. Возможно стоит взять файлы за основу чата?
3. Возможно стоит совместить оба варианта? Т.е. база для тематических комнат, файлы для приватных.

Что можете посоветовать?

не понимаю почему нельзя инт.
даже если у вас может быть НАСТОЛЬКО много комнат (4 млрд??) , то вы можете сделать bigint - это совсем опупеть сколько.

Aeq
Я же описал проблему.
Дополнительно хранить номер комнат в базе? Что бы определить какая комната для каких двух пользователей...

Quieteroks
а что мешает?

Zzepish
Не люблю я плодить таблицы. Тем более даже теоретически, имеем 1 000 000 пользователей, которые могут написать такому же 1 000 000 пользователей, плюс пару десятком тематических и возможно временных чатов. Так что количество может превысить количество допустимых значений...

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

Quieteroks
а что тебе меншает удалять все сообщения при удалении чата???

Quieteroks, помоему вы сейчас взяли и трахнули сами себе мозг...


_____________
Стимулятор ~yoomoney - 41001303250491

чатам 1-на-1 можно дополнительного ид и не задавать, использовать 2 ид участвующих юзеров как составной первич ключ. для остальных чатов хватит инта, если доп. комнаты будут создаваться каждую секунду, то инта хватит на 60 лет (по аналогии с таймстампом), если этого мало, то используйте бигинт. Вы у сообщений какой первич. ключ хотите сделать? я к тому что если вы параноите насчет бигинта у комнат, то тогда по-вашему для ид сообщения вообще совсем не хватит никаких диапазонов для первич. ключа ))) а что если млн пользователей напишут млну пользователей млн сообщений? )))

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

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

с такими объемами (млн юзеров) говорить о файловом хранении вообще смысла нет.

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

Aeq
В принципе вариант с двумя полями может сыграть...
Два поля с int 11, в составной ключ.
Для тематических чатов второе поле в ноль.

Фалы в целом можно представить, если не хранить в одном файле более 100 сообщений и удалять по истечении недели... Хотя стоит ли заморачиваться...

Invis1ble
Даже представить не могу, как пушить новые сообщения...
Клиент же должен запросить данные, а как ему передать без его запроса?

Quieteroks

Invis1ble
Спасибо, приму к сведению.
Может когда то понадобится.
Сейчас нужна история сообщений...