2009-05-19 8 views
2

Comment allez-vous mettre en œuvre des fonctionnalités de messagerie privée comme Bebo/Facebook et d'autres sites de réseautage social?Comment implémenter le courrier privé pour le site Web?

Vous avez la possibilité de poster des commentaires publics sur le profil d'un membre, mais vous pouvez également envoyer un courrier privé. J'envisageais d'utiliser XML et de le stocker simplement comme un champ dans l'enregistrement de cet utilisateur particulier. Cela semble-t-il une mauvaise idée?

Quelqu'un a une meilleure suggestion? Je ne suis pas sûr de savoir quelle serait la meilleure solution.

+0

Pourquoi serait-ce différent de stocker des commentaires réguliers? Parce qu'ils ont besoin d'un état "lu"/"non lu"? – Tormod

+0

Ce n'est pas le cas, la seule différence est un message privé. Je stocke des commentaires en tant que XML dans le champ dans SQL Server, de sorte que vous estimez simplement faire un courrier privé un champ tout en protégeant comment ils sont vus? J'étais juste confus quant à la façon dont le courrier privé a été implémenté, c'est-à-dire s'il s'agissait d'un courrier réel tel qu'un échange ou quelque chose du genre. – James

+0

Désolé j'ai mal lu votre commentaire! Ouais à peu près la seule différence que les commentaires normaux est qu'ils ne sont pas publics et auront des états lus/non lus. – James

Répondre

2

j'ai mal compris ce que vous voulez, mais comment sur la création d'une table de messagerie, avec par exemple

  • Auteur
  • bénéficiaire
  • Sujet
  • message
  • Envoyé
  • Lire (bool)

Et puis ajoutez juste une ligne à cette table quand quelqu'un envoie un message privé à quelqu'un.

+0

Oui, je considérais cette option, cependant, ne serait-il pas préférable de la garder en tant que membre? Comme une table globale comme celle-ci deviendrait énorme? Où, comme s'il s'agissait d'un champ XML membre, il sera significativement plus petit. Cependant, j'ai entendu dire que XML n'est pas toujours le plus rapide à analyser! – James

+0

Je pense que cela semble être le moyen le plus populaire que ma suggestion. Pensez-vous qu'il serait logique d'avoir deux tables séparées pour les commentaires et une pour le courrier privé? Ou juste en avoir un appelé Message et avoir une propriété appelée Private qui est un booléen. – James

+0

Eh bien, vous pourriez le faire dans les deux sens.Je pense que je les aurais probablement dans deux tables séparées, puisque les commentaires sont généralement liés à des articles, etc. Mais si c'est juste un truc de publipostage (comme un poteau mural sur facebook), alors je dirais que votre chemin pourrait fonctionner :) – Svish

2

Je vous recommande vivement de ne pas stocker les messages dans un champ de votre table utilisateur. Cela risque fort de générer des problèmes de performances au fur et à mesure que votre application se développe. Comme une autre réponse suggérée, j'ajouterais une table spécifiquement pour stocker des données de message. Voici un exemple de pseudocode de ce à quoi pourraient ressembler vos tables.

UserTable 
{ 
    ID INT, -- a unique system generated ID 
    USER_ID CHAR(20), -- also unique, this is a user provided ID 
    FIRST_NAME CHAR(40), 
    LAST_NAME CHAR(40), 
    BIRTH_DATE DATE 
} 

UserEmailTable 
{ 
    ID INT, -- a unique system generated ID 
    USER_ID CHAR(20), -- this ties the entry to the record on UserTable 
    EMAIL_ADDR CHAR(128), -- user provided email 
    PRIORITY INT, -- Specifies the users 0..N-th address 
} 

MailTable 
{ 
    ID INT, -- a unique system generated ID 
    SENDER_ID INT, -- this ties the entry to the record on UserTable 
    RECIPIENT_ID INT, -- this ties the entry to the record on UserTable 
    CREATE_DATE DATE, -- record when the message was created by sender 
    READ_DATE DATE, -- record when the message was read by recipient 
    PRIVATE BOOL, -- indicates if this is a private message 
    MESSAGE BLOB -- the message body 
} 

S'il vous plaît gardez à l'esprit, ceci est juste un exemple et il peut ne pas répondre aux préoccupations spécifiques de votre application. Un dernier réflexe: pensez-vous réellement à stocker XML dans un champ directement ou à l'aide d'un outil de mappage XML < -> SQL? Si vous stockez le XML directement, vous ne pouvez pas profiter des capacités de votre base de données. Vos préoccupations au sujet des performances sont valides, mais une base de données bien conçue & devrait facilement être capable de gérer des millions d'enregistrements dans une seule table.

Espérons que ça aide.

+0

Jason, ouais mon souci est que si je faisais une table pour le courrier/commentaires seulement, comme c'est global pour tous les membres, les tables deviendront énormes. Où comme si je leur ai fait un champ dans chaque enregistrement de membre sûrement ceci aboutirait à la récupération plus rapide car vous devez récupérer l'information de membre indépendamment? Je chercherais à stocker le XML directement dans la base de données comme SQL Server 2005 prend en charge le champ XML et en utilisant Guids comme ID unique pour les commentaires/mail. Que pensez-vous? – James

+0

Je préfère avoir une table énorme qu'une table avec une colonne gigantesque de données de texte qui doit être analysée pour être utile. – Svish

+0

Pour ne pas couper les cheveux, mais pourriez-vous s'il vous plaît quantifier «énorme» et «gigantesque»? Dans une base de données moderne, des centaines de millions d'enregistrements sont relativement courants. Des milliards ou même des dizaines de milliards de records ne sont pas inconnus. Si vous placez vos messages dans un champ de la table des utilisateurs, votre application sera probablement à l'échelle réduite. Si rien d'autre, en mettant des messages dans leur propre table, vous aurez plus d'options si la performance devient un problème. –

Questions connexes