алгоритм обмена сообщениями

@bammm · Регистрация: 25.09.2008

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

Здравствуйте
Помогите в алгоритме для следующей задачи
Нужно реализовать обмен сообщениями между зарегистрированными пользователями на php+mysql.
Получил совет создать таблицу msg(id, from_user_id, to_user_id, text, date, parent_msg)
Но я думаю это будет занимать слишком много процессорного времени и ресурсов оперативной памяти даже для того чтобы сформировать список между какими пользователями происходил диалог. Может есть способы пооптимизированнее?
Заранее спасибо

25.09.2008, 14:34

Тебе типа чата нужно? или как форум, чтобы это работало?(я имею ввиду скорость обмена сообщениями у пользователей) всё зависит от колличества пользователей, и частоты написания сообщений...
на колличествах пользователей до 100, я думаю что таблица которую тебе посоветовали будет оптимальным вариантом(можно ещё XML документ использовать, с теми же полями, он при небольшом кол-ве сообщений будет меньше чем БД кушать), по соотношению сложность/эффективность... даже если обмен сообщениям идёт на скорости чата (только надо будет чистить эту таблицу периодически, определить время хранения сообщения, чтобы она не расползалась до слишком больших значений...)

@bammm · 26.09.2008, 11:34 **[ТС]**

подскажите как запрос
"select to_user_id from msg where from_user_id=5;" сделать таким чтобы он выбирал строки с уникальным to_user_id

@iPIPka · 06.02.2011, 21:19

SELECT DISTINCT to_user_id FROM msg WHERE from_user_id=5;
это имелось в виду?
А у меня вопрос есть

Т. к. одно сообщение относится к 2 пользователям (у одного - исходящее, у другого - входящее), то как реализовать удаление?

Добавлено через 31 минуту
Все, разобралась, вопрос отменяется :-)

@evgentus · 06.02.2011, 21:28

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

SELECT DISTINCT to_user_id FROM msg WHERE from_user_id=5;
это имелось в виду?
А у меня вопрос есть

Т. к. одно сообщение относится к 2 пользователям (у одного - исходящее, у другого - входящее), то как реализовать удаление?

Добавлено через 31 минуту
Все, разобралась, вопрос отменяется :-)

Внести еще 2 поля что то типа delete_from и delete_to, и если пользователь удаляет у себя сообщение допустим из входящих проверять не удалил ли другой юзер у себя это сообщение из исходящих(если удалил delete_from будет 0)... И в зависимости удалил или нет, либо ставить значение 0, или удалять запись.
Так сделали?

@iPIPka · 06.02.2011, 21:44

Ага, так! Спасибо.
Вот думаю только, наверное триггер надо написать. Только вот не знаю какой.
Видимо, AFTER UPDATE, но насколько это рационально, сначала обновить запись, а потом удалить ее?

@Dellok · 07.02.2011, 00:14

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

Внести еще 2 поля что то типа delete_from и delete_to, и если пользователь удаляет у себя сообщение допустим из входящих проверять не удалил ли другой юзер у себя это сообщение из исходящих(если удалил delete_from будет 0)... И в зависимости удалил или нет, либо ставить значение 0, или удалять запись.
Так сделали?

зачем же так сложно? По идее, если один удалит сообщение, то в ьд его не будет, а значит и у другого пользователя оно "удалится"

@iPIPka · 07.02.2011, 00:22

Поэтому-то так сложно) Надо так, чтоб если один удалит сообщение, то у второго оно останется, а не пропадет

@evgentus · 07.02.2011, 04:29

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

зачем же так сложно? По идее, если один удалит сообщение, то в ьд его не будет, а значит и у другого пользователя оно "удалится"

Предложите свой вариант реализации ЛС.
Мне кажется этот вариант самый оптимальный, не вижу смысла создавать 2 записи на одно сообщение, пусть в варианте который я озвучил и на 1 запрос больше будет, но БД не будет так сильно разрастаться.

@Dellok · 07.02.2011, 08:28

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

Поэтому-то так сложно) Надо так, чтоб если один удалит сообщение, то у второго оно останется, а не пропадет

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

Мне кажется этот вариант самый оптимальный, не вижу смысла создавать 2 записи на одно сообщение, пусть в варианте который я озвучил и на 1 запрос больше будет, но БД не будет так сильно разрастаться.

Прошу прощения, не правильно понял вопрос.

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

Предложите свой вариант реализации ЛС.

Сейчас находу придумал такой вариант: добавить не 2, а 1 поле, в котором через маркер держать ID получателя и отправителя. Когда один из пользователей удалил письмо, то убирать этот ид из этого поля. Так, имхо, будет лучше, если получатель будет не 1, а несколько.

@evgentus · 07.02.2011, 08:52

Ну в принципе можно так попробовать... Но не получится использовать это для нескольких получателей, объясню...
В том варианте который я предложил, выборка писем происходит скажем по полю inbox и outbox, т.е. в первом хранится id получателя, во втором отправителя, в БД соответственно созданы индексы для этих полей, выборка будет происходить мгновенно, а для нескольких получателей нужно будет хранить например так "1:2:3:4" плохой вариант, ИМХО.
Да и для чего обычному юзеру потребуется отправлять массово письма?! Спамерам и администрации, имхо, письма и от тех и от других юзер сразу удаляет, если конечно он заглядывает в учетку.
Вот так я это всё вижу...

Добавлено через 12 минут
Щас посплю и в своем блоге статью напишу про реализацию ЛС, в своем видении....

@Dellok · 07.02.2011, 16:33

evgentus, для каких целей это должно использоваться, меня не интересует. Я просто помогаю с реализацией.

Новые блоги и статьи Все статьи Все блоги /
Отчёт о спецтехнике находящейся в ремонте Maks 20.04.2026 Отчёт из решения ниже размещен в конфигурации КА2. Задача: отобразить спецтехнику, которая на данный момент находится в ремонте. Есть нетиповой документ "Заявка на ремонт спецтехники" который. . .	Памятка для бота и "визитка" для читателей "Semantic Universe Layer (Слой семантической вселенной)" Hrethgir 19.04.2026 Сгенерировано для краткого описания по случаю сборки и компиляции скелета серверного приложения. И пусть после этого скажут, что статьи сгенерированные AI - туфта и не интересно. И это не реклама -. . .	Запрет удаления строк ТЧ документа при определенном условии Maks 19.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "Аккумуляторы", разработанного в конфигурации КА2. У данного документа есть ТЧ, в которой в зависимости от прав доступа. . .	Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .
Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .	Знаешь почему 90% людей редко бывают счастливыми? kumehtar 14.04.2026 Потому что они ждут. Ждут выходных, ждут отпуска, ждут удачного момента. . . а удачный момент так и не приходит.	Фиксация колонок в отчете СКД Maks 14.04.2026 Фиксация колонок в СКД отчета типа Таблица. Задача: зафиксировать три левых колонки в отчете. Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) / / . . .

@bammm 0 / 0 / 0 Регистрация: 25.09.2008 Сообщений: 5

	алгоритм обмена сообщениями 25.09.2008, 11:43. Показов 5817. Ответов 11 Метки нет (Все метки) Здравствуйте Помогите в алгоритме для следующей задачи Нужно реализовать обмен сообщениями между зарегистрированными пользователями на php+mysql. Получил совет создать таблицу msg(id, from_user_id, to_user_id, text, date, parent_msg) Но я думаю это будет занимать слишком много процессорного времени и ресурсов оперативной памяти даже для того чтобы сформировать список между какими пользователями происходил диалог. Может есть способы пооптимизированнее? Заранее спасибо 0

Гость-1000
	25.09.2008, 14:34
	Тебе типа чата нужно? или как форум, чтобы это работало?(я имею ввиду скорость обмена сообщениями у пользователей) всё зависит от колличества пользователей, и частоты написания сообщений... на колличествах пользователей до 100, я думаю что таблица которую тебе посоветовали будет оптимальным вариантом(можно ещё XML документ использовать, с теми же полями, он при небольшом кол-ве сообщений будет меньше чем БД кушать), по соотношению сложность/эффективность... даже если обмен сообщениям идёт на скорости чата (только надо будет чистить эту таблицу периодически, определить время хранения сообщения, чтобы она не расползалась до слишком больших значений...)

@bammm 0 / 0 / 0 Регистрация: 25.09.2008 Сообщений: 5
	26.09.2008, 11:34 [ТС]
	подскажите как запрос "select to_user_id from msg where from_user_id=5;" сделать таким чтобы он выбирал строки с уникальным to_user_id 0

@iPIPka 39 / 39 / 5 Регистрация: 06.02.2011 Сообщений: 123
	06.02.2011, 21:19
	SELECT DISTINCT to_user_id FROM msg WHERE from_user_id=5; это имелось в виду? А у меня вопрос есть Т. к. одно сообщение относится к 2 пользователям (у одного - исходящее, у другого - входящее), то как реализовать удаление? Добавлено через 31 минуту Все, разобралась, вопрос отменяется :-) 0

@iPIPka 39 / 39 / 5 Регистрация: 06.02.2011 Сообщений: 123
	06.02.2011, 21:44
	Ага, так! Спасибо. Вот думаю только, наверное триггер надо написать. Только вот не знаю какой. Видимо, AFTER UPDATE, но насколько это рационально, сначала обновить запись, а потом удалить ее? 0

@iPIPka 39 / 39 / 5 Регистрация: 06.02.2011 Сообщений: 123
	07.02.2011, 00:22
	Поэтому-то так сложно) Надо так, чтоб если один удалит сообщение, то у второго оно останется, а не пропадет 0

@evgentus 26 / 18 / 1 Регистрация: 05.02.2011 Сообщений: 55
	07.02.2011, 08:52
	Ну в принципе можно так попробовать... Но не получится использовать это для нескольких получателей, объясню... В том варианте который я предложил, выборка писем происходит скажем по полю inbox и outbox, т.е. в первом хранится id получателя, во втором отправителя, в БД соответственно созданы индексы для этих полей, выборка будет происходить мгновенно, а для нескольких получателей нужно будет хранить например так "1:2:3:4" плохой вариант, ИМХО. Да и для чего обычному юзеру потребуется отправлять массово письма?! Спамерам и администрации, имхо, письма и от тех и от других юзер сразу удаляет, если конечно он заглядывает в учетку. Вот так я это всё вижу... Добавлено через 12 минут Щас посплю и в своем блоге статью напишу про реализацию ЛС, в своем видении.... 0

@Dellok 126 / 93 / 18 Регистрация: 09.01.2011 Сообщений: 467
	07.02.2011, 16:33
	evgentus, для каких целей это должно использоваться, меня не интересует. Я просто помогаю с реализацией. 0

Опции темы