Реализация noSQL: многопоточная система обмена сообщениями - PullRequest
Новая
       0

Реализация noSQL: многопоточная система обмена сообщениями

0 голосов
/ 03 декабря 2010

Я пытаюсь построить многопоточную систему обмена сообщениями для моего сайта.В основном система предоставляет следующие функции:

  • позволяет пользователям отправлять сообщения между собой
  • произвольные уровни ответов (потоков)

Я уже пробовал использоватьMySQL и PHP и построил скелет.Однако в целом процесс извлечения потока является своего рода рекурсивным, что, я считаю, не лучшее, что может сделать реляционная схема.Поэтому сейчас я занимаюсь поиском не-SQL-реализации.Надеюсь, чтобы избежать такой проблемы, делая поиск данных более естественным.

У кого-нибудь есть такой опыт, дайте мне подсказку, пожалуйста.

Обновление: Мое клиентское приложение написано на PHP и, вероятно, так и останется.

Ответы [ 2 ]

1 голос
/ 04 декабря 2010

База данных документов или объектная база данных выполнят то, что вы ищете, достаточно хорошо.Есть способы, которыми вы можете сделать это с RDBMS, которая будет работать так же хорошо.Пример схемы: 

CREATE TABLE messages (
  message_id INT,
  original_message_id INT,
  parent_message_id INT,
  message VARCHAR(4000)
);

Затем вы можете выполнить выборки из этой таблицы, например 

SELECT *
FROM messages
WHERE message_id = ? OR original_message_id = ?
ORDER BY parent_message_id;

Это, вероятно, решит вашу проблему.Преимущество выполнения этого с базой данных OODB или документа состоит в том, что вы сможете получить все данные для «разговора», используя только один запрос, поскольку все они хранятся вместе.С другой стороны, вы жертвуете некоторой гибкостью специальных запросов для удобства чтения всех ваших данных одновременно.

0 голосов
/ 14 августа 2011

А как насчет использования темы вместо комментария в качестве основного объекта?Давайте сначала попробуем с SQL и потоком из двух человек: когда первый пользователь отправляет первое сообщение второму пользователю, вы создаете новый поток и связываете этот поток с двумя пользователями (у пользователя много потоков).Само сообщение вы можете сохранить как JSON.Тогда каждый ответ будет в том же JSON (тот же varchar или аналогичное поле).Это решение хорошо работает, если вам не нужно искать (или перечислять) отдельные сообщения.

Пример: 

Users:
Id-Name
1-User1
2-User2

UsersByThread:
UId-TId
1-1
2-1

Threads
Id-JSON
1-'{"messages":[{"user":"User1","text":"blablabla"}]}'

Затем, когда ответит второй пользователь, вы просто берете json и добавляете новое сообщение: 

Threads
Id-JSON
1-'{"messages":[{"user":"User1","text":"blablabla"},{"user":"User2","text":"blablabla"}]}'

Если третье лицоприсоединяясь к ветке, вы просто добавляете связь в UsersByThread и добавляете сообщение в JSON.

Кстати, вы можете использовать ту же идею в магазине nosql, например на диване, или даже в магазине значений ключей, таких как redis.Также вы можете создать более естественную систему в neo4j, но я думаю, что это может работать просто отлично в обычной базе данных sql

...