C# 如何为网站实现私人邮件？

你将如何实现像Bebo/Facebook和其他社交网站这样的私人邮件功能

您可以选择在成员的个人资料上发布公开评论，但也可以发送私人邮件

我正在考虑使用XML并将其作为字段存储在特定用户的记录中。这听起来像个坏主意吗

---

有谁有更好的建议吗？我不确定哪一个是最好的解决方案。

我可能误解了您的要求，但是创建一个邮件表怎么样，例如

• 寄件人
• 接受者
• 主题
• 信息
• 发送
• 阅读（bool）

---

然后，当某人向某人发送私人消息时，只需在该表中添加一行即可。

我强烈建议不要将消息存储在用户表的字段中。随着应用程序的增长，这很可能会导致性能问题。正如另一个答案所建议的，我将添加一个专门存储消息数据的表。下面是表的伪代码示例

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
}

请记住，这只是一个示例，可能无法解决应用程序的具体问题

最后一个想法：您实际上是打算直接在字段中存储XML，还是使用某种XMLSQL映射工具？如果直接存储XML，则可能无法利用数据库的功能。您对性能的担忧是正确的，但是一个经过良好设计和调优的数据库应该能够轻松地在一个表中处理数百万条记录

---

希望这能有所帮助。

为什么它与存储常规评论不同？因为他们需要“已读”/“未读”状态？不是，唯一的区别是它是一条私人消息。我将注释作为XML存储到SQL Server中的字段中，所以您认为将私人邮件也作为字段来保护它们的查看方式吗？我只是搞不清楚私人邮件是如何实现的，也就是说，它是不是真正的邮件，比如exchange之类的。对不起，我看错了你的评论！是的，与普通评论相比，唯一的区别是它们不是公共的，并且会有读/未读状态。是的，我在考虑这个选项，但是，将其保留为成员字段不是更好的性能明智之举吗？像这样一张全球桌子会变得巨大吗？如果它是一个成员XML字段，那么它将大大减小。然而，我听说XML并不总是最快的解析方式！我认为这似乎比我的建议更受欢迎。您认为有两个单独的表（一个用于评论，一个用于私人邮件）有意义吗？或者只需要一个名为Message的属性和一个名为Private的属性，这是一个布尔值。我想我可能会把它们放在两个单独的表格中，因为评论通常与文章等联系在一起。但如果它只是一个公共邮件（比如facebook上的wallpost），那么我会说你的方式可以工作：）还请记住，数据库是用来在巨大的表格中处理大量数据的（至少是“真实的”数据库）。Jason，是的，我担心的是，如果我只为邮件/评论制作一个表格，因为它对所有成员都是全局的，那么表格将变得巨大。如果我在每个成员记录中都将它们作为一个字段，那么这肯定会导致更快的检索，因为不管怎样，您都需要检索成员信息？我希望将XML直接存储到数据库中，因为SQLServer2005支持XML字段，并使用GUID作为注释/邮件的唯一id。你的想法是什么？我宁愿拥有一个巨大的表格，也不愿拥有一个包含大量文本数据的表格，这些文本数据必须经过解析才能发挥任何作用。我不想吹毛求疵，但请你量化“巨大”和“巨大”两个词好吗？在现代数据库中，数亿条记录是相对常见的。数十亿甚至数百亿的记录并非闻所未闻。将消息放入用户表上的字段几乎肯定会导致应用程序伸缩性差。如果没有其他问题，通过将消息放在它们自己的表中，如果性能出现问题，您将有更多的选项。