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

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

Миниатюры

 

0

Сообщение от stashappy Представьте такую ситуацию. Я переписываюсь с собеседником, а затем удаляю свой диалог. В один прекрасный момент, я снова пишу ему сообщение и у меня создается новый диалог с новым id. Теперь, если учесть представленный выше вариант, мой собеседник больше не увидит мои сообщения, так как id моего диалога поменялся. Этот момент мне непонятен. Как правильно подставить данные в выборку?

Да, вы правы, я не правильно составил таблицу, нужно так:
dialogs:
id user1_id user2_id deleted

messages:
id dialog_from_id dialog_to_id

Тогда при новом сообщении от user_id = 1 to user_id = 2
Вы создаете две записи в dialogs
т.е. для каждого из переписчиков по диалогу

и вставляется запись в messages
тогда для выбора сообщений пользователю user_id = 1 (диалог с user_id = 2) нужно
найти диалог, где user1_id =1 and user2_id = 2 (это dialog_id = 1),
затем выбираем из messages все записи с dialog_from_id или dialog_to_id = 1 (dialog_id),
по тому какое поле совпало dialog_from_id или dialog_to_id мы понимаем исходящее это сообщение или входящее. Мы нашли message id = 1 dialog_from_id = 1 dialog_to_id = 2,
по полю dialog_from_id - т.е. для user_id = 1 это исходящее сообщение.
Для пользователя user_id = 2 это сообщения найдется по полю dialog_to_id => оно для него входящее.
Далее если кто-то из них удалит переписку, н-р user_id = 1, то находится его диалог с user_id = 2,
это dialog_id = 1 и ставится deleted = 1, тогда для user_id = 1, для показа сообщений с user_id = 2, мы не найдем диалог => сообщения не выводятся(для user_id = 2 найдется диалог 2 и по нему сообщения найдутся).
Если user_id = 1 возобновит переписку или user_id = 2 снова напишет user_id = 1, то создается новый диалог
для user_id = 1, для user_id = 2 найдется старый(не удаленный):
И новые сообщения между ними (например от user_id = 2 to user_id = 1)
будут записываться с другим номером диалога для user_id = 1, и старым для user = 2:
Тогда user_id = 2 будет видеть все сообщения, а user_id = 1 - только новые.

2

Сообщение от esculap_ra самый большой файл - города России весит 96 кил

вы смеетесь что ли? Города России

По итогам Всероссийской переписи населения 2010 года статус города имеют 1100 населённых пунктов

Вы правда считаете, что база на 1100 населенных пунктов - это здоровая БД, запросы к которой будут тормозить? Конечно, при таком сравнении все будет шустро донельзя.

Сообщение от esculap_ra последовательный перебор пользователем списка стран создаст 218 запросов

Вы вообще, хоть раз, с БД работали? Какие еще 218 запросов? Один запрос, все. Получили указатель на результат запроса, и все, хоть закрывай соединение. Обработали одну запись, сдвинули указатель на следующий. Обработали еще одну запись, сдвинули указатель на следующий. Соединение с БД вообще можно закрыть. Запустите такой код (данные для подключения и запрос укажите свои)
Откуда вы взяли 218 запросов?

Сообщение от esculap_ra и так для каждого пользователя

Да. А JSON, наверное, на всех один, общий?

Сообщение от esculap_ra крупные социальные сети могут позволить себе такую роскошь

Любой нормально спроектированный сайт может позволить себе такую мелочь.

Сообщение от esculap_ra постоянные обращения к БД

Это явно не тот случай, когда происходят постоянные обращения к БД. Если только в вашем понимании.

Сообщение от esculap_ra в моих же разработках на первом плане - уменьшение запросов к серверу и БД

Не используйте в своих разработках вообще БД - никто не против. Но не надо это возводить в статус "единственное и априори верное решение", доказывая при этом то, в чем, по-видимому (судя из 218 запросов), совершенно не разбираетесь. Это не упрек или что-то в этом духе, это констатация факта.

0

zebulun. Ох мой друг. Спасибо вам душевное большое. Спасибо за помощь и поддержку.

Добавлено через 22 минуты

Один запрос, все. Получили указатель на результат запроса, и все, хоть закрывай соединение.

Да, по идее. Нет никаких 218 запросов. Есть только один запрос и один массив, в который мы засовываем результат выборки. А дальше используем простой цикл для извлечения из массива. А 218 запросов.., разве что так можно умудриться:

Вы правда считаете, что база на 1100 населенных пунктов - это здоровая БД, запросы к которой будут тормозить? Конечно, при таком сравнении все будет шустро донельзя.

В моей БД, по России и США, где-то примерно 6000 городов. И 120 регионов и штатов. Выборка производится очень просто и нужен для этого всего один запрос к БД.

0

Сообщение от KOPOJI Вы вообще, хоть раз, с БД работали? Какие еще 218 запросов? Один запрос, все.

вот неправильно выразился (...в чем, по-видимому (судя из 218 запросов), совершенно не разбираетесь... ), и тут сразу уцепились за слова. только 218 запросов к серверу + 218 запросов к БД (на 1 страну 2 запроса - сервер и БД). и да, файл для всех общий (на 1 стрвну - 1 файл с городами). и этот файл слхранится в кэше, поэтому вторичный выбор этого же селекта уже не потребует получения файла, так как указано время истечения действия. но вы при желании можете конечно получать каждый раз эти же данные из БД - никто не возбраняет. так "гибче и рациональнее", и это укладывается в догму.

на 1100 населенных пунктов - это не здоровая БД, но если представить гипотетически одновременные запросы от 1000 пользователей, от 10 тыс. и при этом еще учесть кучу запросов на получение технических файлов - скрипты и стили. вот поэтому большинтсво сайтов по скорости загрузки оставляют желать лучшего.

спасибо за приведенный код. но эти все действия у меня выполняет класс для работы с БД и неплохо с этим спарвляется.

трудно разговаривать с прожженными консерваторами. и это тоже констатация факта....

0

Сообщение от esculap_ra но вы при желании можете конечно получать каждый раз эти же данные из БД

я уже говорил про memcached. Он как раз для этого.

Сообщение от esculap_ra и тут сразу уцепились за слова

Не уцепился, а увидел, что вы говорите, извиняюсь, чушь. Вот откуда вы это взяли:

Сообщение от esculap_ra только 218 запросов к серверу + 218 запросов к БД

Можете рассказать ваше понимание того, как устроена связь между СУБД - PHP - Клиент ? А то, видимо, все (в том числе и сами разрабы) ничего не понимают в устройстве трехуровневой архитектуры. И многие сайты используют БД, наверное, потому, что не понимают, что вы, как истинный профессионал, решительно утверждаете, что эта архитектура - туфта, и обычная архитектура клиент-сервер в 100 раз лучше. Да, у нее есть и минусы, как и у любой другой - но в вебе, зачастую, она куда более предпочтительна. Почитайте, что ли, хоть что это такое Трехуровневая архитектура Клиент-сервер

Сообщение от esculap_ra на 1100 населенных пунктов - это не здоровая БД, но если представить гипотетически одновременные запросы от 1000 пользователей, от 10 тыс. и при этом еще учесть кучу запросов на получение технических файлов - скрипты и стили. вот поэтому большинтсво сайтов по скорости загрузки оставляют желать лучшего.

Еще раз:

Сообщение от KOPOJI JSON, наверное, на всех один, общий?

Обращение к файлу будет также производиться от каждого пользователя. Напомнить расшифровку JSON ?

Сообщение от esculap_ra трудно разговаривать с прожженными консерваторами

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

Добавлено через 8 минут
В общем, esculap_ra, если у вас нет ничего, кроме "мое лучшее имхо", то просьба ничего не писать.. Или предоставьте доказательства или хотя бы корректное утверждение того, что ваша идея лучше, или успокойтесь и хватит кидаться на всех с "консерватор"

0

1. В связанных селектах города-страны 218 стран(первичный селект)
2. В файле 1 раз записывается данные по городам для страны (для россии, например, это будет файл 1.json). по сути это тот же кэш полученных единожды данных и сериализированных данных. их то все равно необходимо сериализовать для передачи по сети.
3. Если такой файл еще не создавался, то клиент передает запрос на обработчик (скрипт geo.php): 1 раз для америки, 2-ой раз для россии, 3-тий раз для украины и т.д., в зависимости от выбираемого пункта. При этом сервер создает 1 запрос к БД чтобы получить эту инфу. Если же файл уже существует, то он просто скачивается минуя скрипт обработчика методом get в ассинхронном запросе и кэшируется на стороне клиента. И полученные данные (все города для конкретной страны) появятся во втором селекте.

Эту фразу "JSON, наверное, на всех один, общий?" я понял неправильно, и говоря что общий имел в виду один для списка городов по каждой стране.

И давайте заканчивать беспредметную полемику.

0

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

один запрос.

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

В двух таблицах 1 раз записываются города и страны
countries

country_id

country

cities

city_id

country_id

city

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

Если такой запрос еще не был выполнен, то он выполняется, данные кэшируются. С учетом использования индексов - запрос выполняется ~0.01 секунд для 1000 записей. Может, меньше, не знаю. При этом сервер создает 1 запрос к БД с JOIN-ом, чтобы получить эту инфу. Если уже есть информация в кэше - он берет информацию оттуда.

Сообщение от esculap_ra И давайте заканчивать беспредметную полемику.

И правда, сначала почитайте что-нибудь по этой теме, потом можно будет поговорить.

0

zebulun. Я что-то явно делаю неправильно. Когда отправляю пользователю сообщение(диалог возобновляется), я отправляю ему свой старый dialog_id(=1) и его dialog_id(=2). А как я увижу это своё отправленное сообщение? Ведь делаю выборку у себя в кабинете по другим данным: dialog_id=2 и dialog_id=3.

0

А зачем вообще разделять на "диалоги-сообщения", если хотите "как в вконтакте" ? Вроде, там такого разделения нет.

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

Сообщение от stashappy Когда отправляю пользователю сообщение(диалог возобновляется)

Когда наступает тот период, что диалог не должен возобновляться?

0

Когда наступает тот период, что диалог не должен возобновляться?

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

0

stashappy, ну вот, смотрите. Есть стопка сообщений

я: привет она: привет я:.... она:... ____________ прошло полгода я:..... она:..... я:..... она:..... прошло полгода я:..... она:.....

Я удаляю диалог. Какие сообщения у меня удалятся? Все? Если да - то какой смысл от лишней таблицы "диалоги" ?

0

я: привет она: хай я: пока // здесь я удалил свой диалог //через пол года пишу ей опять и диалог возобновляется я: привет она: hi

В итоге. После того, как я удалил свой диалог и после того, как я снова возобновил его, я буду видеть только новые сообщения. А она, должна видеть все сообщения(так как её диалог не был никем удалён).

0

0

лично я вижу мало смысла на разделение с таблицей диалоги

KOPOJI. А у вас есть вариант получше этого? Я как-то помнится тоже пробовал обойтись всего одной таблицей, но ничего не получилось.

0

Например, использовать не таблицу диалоги, а таблицу с удаленными сообщениями. Или в одной таблице все оставлять

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

0

Какие сообщения у меня удалятся? Все?

Сообщения, сами по себе, они не удаляются. Они всё так-же продолжают сидеть в БД. Но при удалении и последующем возобновлении диалога, просто меняется его dialog_id. И старые сообщения, которые не соответствуют этому dialog_id, не будут показываться для меня. Но всё ещё должны показываться для моего собеседника, до тех пор, пока он не удалит свой диалог.

0

Сообщение от stashappy Когда отправляю пользователю сообщение(диалог возобновляется), я отправляю ему свой старый dialog_id(=1) и его dialog_id(=2). А как я увижу это своё отправленное сообщение? Ведь делаю выборку у себя в кабинете по другим данным: dialog_id=2 и dialog_id=3.

Во-первых вы, как пользователь, диалоги не отправляете, а только сообщения.
Во-вторых, когда пользователь отправил кому-либо сообщение, в таблице dialogs ищутся две записи,
одна для того чтобы привязать это сообщение к отправителю, другая к получателю по условию:
user1_id=id пользователя к которому привязывается сообщение(повторяю привязывается к отправителю и получателю,у меня там опечатка в описании dialogs, два раза написал user2_id в названиях столбцов, первый из них это user1_id)
AND
user2_id = id второго участника диалога AND deleted = 0, если такого совпадения не нашлось для кого-то из переписчиков(н-р отправитель удалил переписку(когда он удалил переписку со вторым пользователем, то запись в dialogs, где user1_id=id того кто удалил, user2_id = id того с кем была переписка помечается как удаленная)), то для того для кого не нашлось записи в dialogs, создается новая запись с новым id в таблице dialogs, но значения user1_id и user2_id не меняются, поэтому когда вы ищете сообщения, которые нужно показывать, вы находите запись в dialogs, где user2_id = id того, с кем переписка,и по id этой записи, ищете все сообщения в messages. Получается, пока юзер не удалил переписку, id его диалога не поменяется, и те сообщения, которые уже не видны, тому, из двух кто удалил переписку останутся видны, тому кто не удалял.
Почему вы не увидите свое новое сообщение, после возобновления диалога?

1

Добавлено через 12 минут
первое, что бросилось в глаза, это зачем в таблице диалогов, делать две связи, в обе стороны?
второе, зачем два юзера в таблице мессагес?

Добавлено через 6 минут
subjects
id, [user_id,] [title,] [time,] [flags]
по сути главное id
флаги могут быть, закрыта, приватная, общая... вообщем всё на что фантазии хватит и бит в поле
можно хранить в юзер ид - создателя диалога, или убрать поле

dialogs
subject_id, user_id, flags
первичный ключ по 2 полям
флаги могут для конкретного юзера быть, например подписаться, оповещать, удалить...

messages
id, subject_id, user_id, time
собственно ид дилаога для которого сообщение
и ид юзера который отправил.

чем не устраивает такой подход?

1

Доброй ночи, почитал вашу дискуссию..)

есть схожая задача - диалоги

структуру БД прикрепил

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

по функционалу - только переписка между двумя пользователями, нет удаления сообщений. всего пользователей до 20

Миниатюры