Implémentation de noSQL: système de messagerie à threads

Question

J'essaie de créer un système de messagerie à thread pour mon site Web. Fondamentalement, le système offre des fonctionnalités suivantes:

• permettent aux utilisateurs d'envoyer des messages entre les uns des autres
• niveaux arbitraires de réponses (fils)

je l'ai déjà essayé d'utiliser MySQL + PHP et a construit un squelette. Cependant, dans l'ensemble de la partie récupération de threads est un peu récursif, ce qui, je crois, n'est pas la meilleure chose qu'un schéma relationnel peut faire. Alors maintenant, je suis à la recherche d'une implémentation non-SQL. Espérons éviter un tel problème rendant la récupération de données plus naturelle.

Quelqu'un a une telle expérience me donner un indice s'il vous plaît.

Mise à jour: Mon application cliente est écrite en PHP et le restera probablement.

Answer 1

Une base de données de documents, ou une base de données d'objets, accomplira ce que vous cherchez plutôt bien. Il y a des façons que vous pouvez également faire avec un SGBDR qui fonctionnera tout aussi bien. Un exemple de schéma est:

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

Vous pouvez ensuite effectuer une sélection dans ce tableau comme

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

Ce serait probablement résoudre votre problème. L'avantage de faire cela avec une base de données OODB ou document est que vous serez en mesure de retirer toutes les données pour une «conversation» en utilisant une seule requête, puisque tout est stocké ensemble. En revanche, vous sacrifiez une certaine flexibilité de requête ad hoc pour la commodité de lire toutes vos données à la fois. Qu'en est-il de l'utilisation du thread à la place du commentaire en tant qu'entité principale?

Answer 2

Essayons d'abord avec SQL et un thread à deux personnes: lorsque le premier utilisateur envoie le premier message au second utilisateur, vous créez un nouveau thread, et liez ce thread avec les deux utilisateurs (l'utilisateur a beaucoup de threads). Le message lui-même vous pouvez le stocker en tant que JSON. Ensuite, chaque réponse sera dans le même JSON (même champ varchar ou similaire). Cette solution fonctionne bien si vous n'avez pas besoin de rechercher (ou de lister) des messages individuels.

Exemple:

Users: 
Id-Name 
1-User1 
2-User2 

UsersByThread: 
UId-TId 
1-1 
2-1 

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

Ensuite, lorsque le second répondre utilisateur, vous simplement prendre le JSON, et ajouter un nouveau message:

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

Si une tierce personne se joindre au fil, il vous suffit ajoutez la relation dans UsersByThread et ajoutez le message dans le JSON. Par ailleurs, vous pouvez utiliser la même idée dans un magasin nosql comme canapé, ou même dans un magasin de valeurs-clés comme Redis. Aussi, vous pouvez créer un système plus naturel dans neo4j, mais je pense que cela pourrait fonctionner tout simplement bien dans une base de données SQL régulière