Диалоги между пользователями

@stashappy · Регистрация: 21.08.2011

Студворк — интернет-сервис помощи студентам

Добрый день. Помогите пожалуйста решить логическую задачу. У себя пытаюсь реализовать что-то наподобие диалогов между пользователями. Примерно как вконтакте. Итак, сделал две таблицы. Одну для диалогов, другую для сообщений. Таблица для сообщений, представлена на рисунке. Вопрос. Как построить таблицу для диалогов? Какие поля там должны быть?

@stashappy · 07.02.2014, 12:40 **[ТС]**

Был когда то такой вариант таблицы для диалогово(на рисунке). При выборке данных, я смотрел, имеются ли у меня активные диалоги с тем или иным пользователем. Затем, если что-то находилось, то выводил сообщения на страницу. Мой недочёт был в следующем. При удалении диалога, я ставил flag диалога в положение '0' и затем, удалял из таблицы все сообщения с этого диалога. А потом смекнул, что сообщений может быть очень много и подобные операции будут постоянной нагрузкой для сервера. И вот, теперь.. Я не знаю что делать и как быть.

@zebulun · 08.02.2014, 13:13

Как по мне в таблице сообщения поля id-отправителя и получателя не нужны(это должны быть атрибуты диалогов), а поля dialog_id не хватает.

@stashappy · 08.02.2014, 13:59 **[ТС]**

Как по мне в таблице сообщения поля id-отправителя и получателя не нужны(это должны быть атрибуты диалогов), а поля dialog_id не хватает

Интересная мысль. Спасибо. А как мы будеа манипулировать с dialog_id?

@zebulun · 08.02.2014, 14:13

При удалении диалога с id=x, удаляются сообщения с dialog_id=x или вы о чем?

@stashappy · 08.02.2014, 14:22 **[ТС]**

При удалении диалога с id=x, удаляются сообщения с dialog_id=x или вы о чем?

Да, я об этом. Но опять же встает вопрос. А что если сообщений будет много? Такие операции удаления нагружают сервер. У меня есть мысль, но не знаю как её реализовать. А именно. При удалении диалога, не просто обнулить его flag, а также обновить его dialog_id на другое значение. И получится так, что старые сообщения удалять из базы не придётся. Они просто не будут уже показываться, так как dialog_id уже обновился и они будут считаться удаленными. Что скажете?

@zebulun · 08.02.2014, 14:39

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

@esculap_ra · 08.02.2014, 14:54

Есть вариант:
таблица диалога: id, messages
ид находятся в таблицах обоих собеседников.
messages хранит все диалоги в json-формате. например [{id:1,answer:"a-la-la",question:"bla-bla-bla"},{...},{...}]
Одна запись используется для обоих пользователей. Осталось реализовать извлечение и запись данных в это поле (что очень несложно).

@zebulun · 08.02.2014, 15:08

Сообщение от esculap_ra

Есть вариант:
таблица диалога: id, messages
ид находятся в таблицах обоих собеседников.
messages хранит все диалоги в json-формате. например [{id:1,answer:"a-la-la",question:"bla-bla-bla"},{...},{...}]
Одна запись используется для обоих пользователей. Осталось реализовать извлечение и запись данных в это поле (что очень несложно).

Это не рационально, постоянно вертеть большие json-объекты, для вставки новых сообщений, и не гибко, удалять конкретные сообщения вообще - пичаль.
dialogs:
id user_from_id user_to_id deleted

messages:
id dialog_from_id dialog_to_id text deleted

@stashappy · 08.02.2014, 15:18 **[ТС]**

почему тогда просто не проверять, если у диалога поле deleted=1

Хорошо, мы поставим deleted=0. А что если этот пользователь в один прекрасный день, напишет своему старому собеседнику новое сообщение. И получается так, что нам надо вывести только новые сообщения, а старые, которые всё ещё сидят в базе данных, нам показывать не надо. Вот этот механизм, я никак не могу продумать. Как отсечь старые сообщения(не удаляя их из базы данных).

messages хранит все диалоги в json-формате

Ох это конечно интересная мысль, но всё равно не вариант.

@zebulun · 08.02.2014, 15:23

Сообщение от stashappy

Хорошо, мы поставим deleted=0. А что если этот пользователь в один прекрасный день, напишет своему старому собеседнику новое сообщение. И получается так, что нам надо вывести только новые сообщения, а старые, которые всё ещё сидят в базе данных, нам показывать не надо. Вот этот механизм, я никак не могу продумать. Как отсечь старые сообщения(не удаляя их из базы данных).

Ох это конечно интересная мысль, но всё равно не вариант.

Это будет просто новый диалог с новым id для старых юзеров, вот и всё.

@stashappy · 08.02.2014, 15:30 **[ТС]**

Это будет просто новый диалог с новым id для старых юзеров, вот и всё.

Понял. И ещё один момент. Правильно ли я понимаю механизм. При отправке сообщения, мы сначала проверяем, есть с данным пользователем в базе данных активный диалог. Если нет, то мы создаём два диалога - для себя и для собеседника.
Пример так:

PHP
1
2
3
$my_id = 555;
$user_id = 777;
mysql_query("INSERT INTO `tab_dialogs` (`my_id`, `user_id`, `deleted`) VALUES (`$my_id`, `$user_id`, `1`), (`$user_id`, `$my_id`, `1`)");

А потом, каждый из пользователей, у себя в кабинете делает выборку из БД, каждый для своего диалога. Правильно я понял?))

@zebulun · 08.02.2014, 15:42

Да, только пару моментов, во-первых поле deleted означает удален, поэтому для активных диалогов оно должно быть равным 0, а не 1(если в таблице значение этого поля по умолчанию поставить 0, то при создании диалогов его вообще упоминать не придется),
во-вторых имена полей подберите верней, они должны быть "говорящими", а то по полю `my_id`, можно подумать, что у вас диалоги не все со всеми, а только вы со всеми, я бы сделал так:

SQL
1
INSERT  INTO dialogs (user_from_id, user_to_id) VALUES (1,2), (2,1)

@stashappy · 08.02.2014, 16:00 **[ТС]**

dialogs:
id user_from_id user_to_id deleted

messages:
id dialog_from_id dialog_to_id text deleted

Это ваш вариант, который мне стоит рассмотреть в данном случае?)

Добавлено через 7 минут
Почему у вас в dialogs, нет поля dialog_id?

KOPOJI · 08.02.2014, 16:07

а чем не устраивает эта структура? Хранение друзей в базе данных mysql Все тоже самое, добавить только текстовое поле, и все...

Добавлено через 33 секунды

Сообщение от stashappy

Почему у вас в dialogs, нет поля dialog_id?

потому что есть поле id

@stashappy · 08.02.2014, 16:13 **[ТС]**

потому что есть поле id

Но обычно это auto_increment. И я его никогда не использовал. Обычно генерировал идентификатор для конкретной записи в таблице, примерно так:

PHP
1
2
3
$rnd = mt_rand(111,999);
$md5_rnd = md5($rnd);
$dialog_id = substr($md5_rnd, 0, 7); // это вставляем в запрос

А уж затем подставлял в запрос.

@zebulun · 08.02.2014, 16:17

Зачем генерировать? Для того и нужен auto_increment, чтоб записи вставлялись с уникальным идентификатором.

@stashappy · 08.02.2014, 16:37 **[ТС]**

Зачем генерировать? Для того и нужен auto_increment, чтоб записи вставлялись с уникальным идентификатором.

Хорошо. Благодарю за поддержку и помощь. О результатах непременно отпишусь.))

Добавлено через 14 минут
Хм. Сразу возникает ещё один вопрос. Скажем, в таблице у меня имеется мой удалённый диалог и активный диалог пользователя. Я пишу ему новое сообщение. Что должно происходить с мои диалогом? И диалогом пользователя?

Добавлено через 2 минуты
Почему спрашиваю? Если id имеющихся диалогов у нас не обновляются, то как я скрою от себя удаленные сообщения? Ведь по идее, если deleted снова станет в положение 0, то я снова увижу свои старые сообщения. А я их видеть не должен.

@zebulun · 08.02.2014, 16:48

Я же писал вроде, что после возобновления диалога вы создаете новый диалог для себя, для собеседника продолжаете писать в его старый диалог(он же свой не удалил), почему он снова станет deleted = 0, следите за тем, чтобы не стал, или удаляйте полностью из таблицы, если вам не нужна возможность восстанавливать старые или создайте еще одну таблицу archive_dialogs куда помещайте удаленные - вариантов много, смотря какие конкретно у вас потребности?

@stashappy · 08.02.2014, 16:52 **[ТС]**

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

Ах, вон оно как оказывается. Спасибо. Теперь я это осознал. Благодарю вас.

Новые блоги и статьи Все статьи Все блоги /
Настройка записи справочника по регистру сведений Maks 29.03.2026 Решение ниже реализовано на примере нетипового справочника "ТарифыМобильнойСвязи" разработанного в конфигурации КА2, с целью учета корпоративной мобильной связи в коммерческом предприятии. . . .	Автозаполнение реквизита при выборе элемента справочника Maks 27.03.2026 Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. При выборе "Спецтехники" (Тип Справочник. Спецтехника), заполняется. . .	Сумматор с применением элементов трёх состояний. Hrethgir 26.03.2026 Тут. https:/ / fips. ru/ EGD/ ab3c85c8-836d-4866-871b-c2f0c5d77fbc Первый документ красиво выглядит, но без схемы. Это конечно не даёт никаких плюсов автору, но тем не менее. . . всё может быть. . .	Автозаполнение реквизитов при создании документа Maks 26.03.2026 Программный код из решения ниже размещается в модуле объекта документа, в процедуре "ПриСозданииНаСервере". Алгоритм проверки заполнения реализован для исключения перезаписи значения реквизита,. . .
Команды формы и диалоговое окно Maks 26.03.2026 1. Команда формы "ЗаполнитьЗапчасти". Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. В качестве источника данных. . .	Кому нужен AOT? DevAlt 26.03.2026 Решил сделать простой ланчер Написал заготовку: dotnet new console --aot -o UrlHandler var items = args. Split(":"); var tag = items; var id = items; var executable = args;. . .	Отправка уведомления на почту при создании или изменении элементов справочника Maks 24.03.2026 Программная отправка письма электронной почты на примере типового справочника "Склады" в конфигурации БП3. Перед реализацией необходимо выполнить настройку системной учетной записи электронной. . .	модель ЗдравоСохранения 5. Меньше увольнений- больше дохода! anaschu 24.03.2026 Теперь система здравосохранения уменьшает количество увольнений. 9TO2GP2bpX4 a42b81fb172ffc12ca589c7898261ccb/ https:/ / rutube. ru/ video/ a42b81fb172ffc12ca589c7898261ccb/ Слева синяя линия -. . .

@stashappy 42 / 42 / 13 Регистрация: 21.08.2011 Сообщений: 625

	Диалоги между пользователями 07.02.2014, 12:33. Показов 13378. Ответов 58 Метки php, диалоги, сообщения (Все метки) Добрый день. Помогите пожалуйста решить логическую задачу. У себя пытаюсь реализовать что-то наподобие диалогов между пользователями. Примерно как вконтакте. Итак, сделал две таблицы. Одну для диалогов, другую для сообщений. Таблица для сообщений, представлена на рисунке. Вопрос. Как построить таблицу для диалогов? Какие поля там должны быть? Миниатюры 0

@stashappy 42 / 42 / 13 Регистрация: 21.08.2011 Сообщений: 625
	07.02.2014, 12:40 [ТС]
	Был когда то такой вариант таблицы для диалогово(на рисунке). При выборке данных, я смотрел, имеются ли у меня активные диалоги с тем или иным пользователем. Затем, если что-то находилось, то выводил сообщения на страницу. Мой недочёт был в следующем. При удалении диалога, я ставил flag диалога в положение '0' и затем, удалял из таблицы все сообщения с этого диалога. А потом смекнул, что сообщений может быть очень много и подобные операции будут постоянной нагрузкой для сервера. И вот, теперь.. Я не знаю что делать и как быть. Миниатюры 0

@zebulun 71 / 71 / 13 Регистрация: 01.09.2011 Сообщений: 379
	08.02.2014, 13:13
	Как по мне в таблице сообщения поля id-отправителя и получателя не нужны(это должны быть атрибуты диалогов), а поля dialog_id не хватает. 1

@zebulun 71 / 71 / 13 Регистрация: 01.09.2011 Сообщений: 379
	08.02.2014, 14:13
	При удалении диалога с id=x, удаляются сообщения с dialog_id=x или вы о чем? 0

@zebulun 71 / 71 / 13 Регистрация: 01.09.2011 Сообщений: 379
	08.02.2014, 14:39
	почему тогда просто не проверять, если у диалога поле deleted=1, то не показывать, если у вас все от диалога пляшет? Вы же выбираете для пользователя сначала диалоги, а потом сообщения связанных с этим диалогом(естественно "потом" - это образно, все делается одним запросом). 0

@esculap_ra 462 / 265 / 55 Регистрация: 22.08.2010 Сообщений: 1,204 Записей в блоге: 4
	08.02.2014, 14:54
	Есть вариант: таблица диалога: id, messages ид находятся в таблицах обоих собеседников. messages хранит все диалоги в json-формате. например [{id:1,answer:"a-la-la",question:"bla-bla-bla"},{...},{...}] Одна запись используется для обоих пользователей. Осталось реализовать извлечение и запись данных в это поле (что очень несложно). 1

@zebulun 71 / 71 / 13 Регистрация: 01.09.2011 Сообщений: 379
	08.02.2014, 16:17
	Зачем генерировать? Для того и нужен auto_increment, чтоб записи вставлялись с уникальным идентификатором. 1

@zebulun 71 / 71 / 13 Регистрация: 01.09.2011 Сообщений: 379
	08.02.2014, 16:48
	Я же писал вроде, что после возобновления диалога вы создаете новый диалог для себя, для собеседника продолжаете писать в его старый диалог(он же свой не удалил), почему он снова станет deleted = 0, следите за тем, чтобы не стал, или удаляйте полностью из таблицы, если вам не нужна возможность восстанавливать старые или создайте еще одну таблицу archive_dialogs куда помещайте удаленные - вариантов много, смотря какие конкретно у вас потребности? 1