Как создать систему диалогов?

Question

[Вячеслав]

Есть торговая площадка на opencart.
Нужно к ней добавить возможность общения между продавцом и покупателем посредством лайв чата (ничего готового не нашел).

Уже 3й день читаю про веб соккеты, качаю всевозможные демки, ковыряю, но со временем все только больше перемешивается.

Буду рад любой структурированной информации, ссылкам и тп.

Comments

[archelon]

подключите jivosite (или аналог) и не мучайтесь

[Вячеслав]

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

[archelon]

w27, невнимательно прочитал вопрос, сорри.

Answer 1

[ThunderCat]

А в чем собсно проблема? там же все довольно прозрачно, что конкретно не понятно? Структура базы? Яваскрипт чата? Код сервернрй части?

Comments

[Вячеслав]

ThunderCat, у меня опыта с php и mysql прям очень мало, до этого момента занимался только версткой и скриптами небольшими.

вчера вроде как была ясность насчет базы сегодня понял что что то не то)
разбирал примеры:
Как правильно спроектировать MYSQL для чата на node.js?
Проектирование схемы базы данных для системы сообщений?

Если учесть, что пользователи у меня уже есть (от opencart), достаточно ли мне вот таких двух таблиц, подскажете?
Всего 2 участника по умолчанию (продавец, покупатель), статус сообщения (прочтено/или нет), нужен только для них. Модератор сможет только просматривать.

dialog[
    'user_id' => 'int(11) NOT NULL',
    'dialog_id' => 'int(11) NOT NULL',
    'created_at' => 'timestamp NOT NULL',
]

messages[
    'message_id' => 'pk',
    'dialog_id' => 'int(11) NOT NULL',
    'author_id' => 'int(11) NOT NULL',
    'type' => 'int(11) NOT NULL',
    'status' => 'int(11) NOT NULL',
    'message' => 'longtext NOT NULL',
    'created_at' => 'timestamp NOT NULL',
]

[ThunderCat]

Вячеслав, в принципе, так как у вас в диалоге всегда участвует не более 2 человек, можно ограничиться 1 таблицей:
id | from_id | to_id | body | datetime | readed | deleted
через нее все спокойно реализуется на уровне 3-4 запросов.

[Вячеслав]

ThunderCat, По чуть чуть продвигаюсь. Все же разбил на 3 таблицы.
Как закончу распишу все))
Из за разбиения возникла небольшая проблемка. Возможно ли при добавлении записи в базу проверить есть ли в таблице уже строка ключ->значение? И если есть соответствие ничего не делать?
Нашел методы “INSERT IGNORE”, “INSERT … ON DUPLICATE KEY UPDATE” но это не совсем то что мне нужно как я понял, подскажете как быть?
Мне это нужно для проверки, общались ли пользователи в диалоге ранее? Чтобы не добавлять в таблицу новую строку.


То есть получаю я данные: dialog_id=3, user_id=22
Проверяю есть ли в таблице dialog строка с такими данными, если есть ничего не делаю, если нет, добавляю.

[ThunderCat]

Вячеслав,

Возможно ли при добавлении записи в базу проверить есть ли в таблице уже строка ключ->значение? И если есть соответствие ничего не делать?

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

[Вячеслав]

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

[ThunderCat]

Вячеслав,

Если у них уже была переписка, запись создаваться не должна), затратно на мой взгляд, как Вы считаете?

Считаю не затратно. Один запрос по 2 цифровым индексированным полям это даже учитывать смешно, выборка будет порядка сотых/тысячных секунды даже на большом массиве данных. Профит же очевиден - логику запросов будет на порядок легче создать. Кроме того вы делаете ровно то же самое + апдейт или игнор, но точно не будете знать был ли у них до этого диалог. Раз вы завели эту таблицу, то наверняка строите (или будете строить) какую-то дополнительную логику вокруг наличия этой связи. И еще - емнип запросы на инсерт-игнор/инсерт-апдейт больше времени занимают.

Answer 2

[Виктор]

Я делал такой чат https://github.com/CppComet/Star.Comet-Chat можете посмотреть его устройство и задать мне вопросы если что то будет не ясно. ( Мои контакты есть в профиле)

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