Показать сообщение отдельно
Старый 17.10.2015, 16:56   #2
h1dd3n
Бывалый
 
Аватар для h1dd3n
 
Регистрация: 19.06.2008
Сообщений: 679
Написано 264 полезных сообщений
(для 450 пользователей)
Ответ: Чат: PHP + MySQLi или что то другое?

Во-первых с точки зрения удобства пользования:

Зачем нужно проверять беседу при создании на "дубликацию" ?
Если в скайпе ты создал конференцию A в которой есть Ты, Вася и В.В. Путин, то при создании конференции Б в которой есть все те же товарищи не должно быть ошибки - это же 2 разные конференции, и там сообщения разные. Или если у тебя есть 2 друга и вы вместе сидите в конференции "Беседка C++" (вас там только 3) и также вы сидите в конференции "Беседка PHP" (вас там тоже только 3) никаких проблем в этом нету. 2 разные конференции - 2 разные чата (хоть и набор пользователей идентичен).

И к тому же групп. чаты (беседы, комнаты, конференции) как правило не создаются с указанием пользователей сразу - ты сначала создаешь чат "Обсуждение Fallout 4", а потом туда пользователей добавляешь (или удаляешь).

Во-вторых насчет структуры в БД:

Если у тебя реляционная база, то классическим вариантом будет users, chats, chat_user_links. В users - пользователи, в chats - чаты, в chat_user_links связи пользователей и чатов (в минимальном варианте 2 колонки chatId, userId).
В этом варианте у тебя:
Быстрый поиск всех пользователей в чате.
Быстрый поиск всех чатов у пользователя.
Что еще нужно?

В-третьих насчет "переписки":

Сама переписка к базе никакого отношения не имеет.
Переписка это получение и доставка сообщений (как 1х1 так и 1хдохрена).
И тут может быть (на факт что обязательно будет, но может появится) проблема в PHP. Весь вопрос в том как ты собираешься в php держать соединения с пользователями (само tcp соединение конечно держит http сервер, но суть в том как устроена обработка событий с этих соединений). Есть разные подходы, и если на малом кол-ве клиентов они все дают одинаковый результат то при увеличении некоторые варианты дают совсем херовый результат (тут тебе придется изучить технологию на которой ты пишешь)

Когда ты написал про базу, я так понимаю ты имел в виду "где и как хранить историю? и каким образом отдавать ее юзерам?".
В целом ответ 1 - хранить историю на клиенте (это можно сделать и веб приложении, а в мобильном/десктопном и подавно). Если прям нужно чтобы и на сервере хранилась, то записывать и на сервер и на клиент. Тогда с сервера тянуть историю будут только те у кого ее по каким-то причинам нет (только что присоединившийся пользователь, пользователь который у себя историю потер и т.д.). В этом случае нагрузка будет уже совсем не большая.
__________________
(Offline)
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
St_AnGer (17.10.2015)