聊天应用程序如何为特定聊天生成ID？

Question

假设我有两个用户，“ Matt”和“ Kevin”。 马特（Matt）想向凯文（Kevin）发送消息，方法是单击聊天按钮，向凯文（Kevin）发送直接消息，聊天框启动，他发送消息，凯文（Kevin）收到消息。

我通过将发送消息的人（Matt）和接收消息的人（Kevin）合并为一个ID来生成聊天ID。

var me = "Matt";
var user = "Kevin";
var uniqueChatID = me+user;

当我保存消息服务器端（使用mongoDB）时，消息对象的chatID为MattKevin 。 因此，现在当我想返回该聊天时，我可以使用chatID的MattKevin提取所有消息。

这样做很好，直到Kevin希望与Matt进行聊天，然后ID变成KevinMatt 。 现在，我引用的是另一个聊天，它倒退了。 因此，如果我想传递uniqueChatID来获取消息，它将提取一个不同的集合。

var me = "Kevin";
var user = "Matt";
var uniqueChatID = me+user;

所以我很好奇我该如何更好地进行设置，以便我的程序知道，好吧，马特和凯文聊天，所以如果马特向凯文发送聊天信息，反之亦然，凯文向马特发送短信，并且得到相同的信息？

Answer 1

按字母顺序对它们进行排序：

var me = "Kevin";
var user = "Matt";
var uniqueChatID = [me, user].sort().join('');

就是说，尽管这在技术上可行，但我建议您做一些整理工作-确保它们始终为小写，并确保在数据库上强制使用唯一的用户名。 或者，我什至建议给用户一个唯一的标识符（如UUID），并使用它来创建UCID：

var me = CurrentUser.uuid(); // 8cb3ebb8-30f9-11e5-a151-feff819cdc9f
var targetUser = Chat.targetUser(); // Matt: 9bc1ef9c-6719-4041-afd3-c5b87c90690d
var uniqueChatID = [me, targetUser].sort().join(',');
// 8cb3ebb8-30f9-11e5-a151-feff819cdc9f,9bc1ef9c-6719-4041-afd3-c5b87c90690d

最后，如果您的数据库支持关系或连接，则最好的选择是为每个聊天分离聊天表/集合，并在用户和聊天之间“连接”（或创建一个关系）。 然后，下次您进行加载时，该连接将使您进入连接到两个用户的唯一聊天。

Answer 2

我认为您的方法太复杂了。 此外，您似乎想将各个聊天消息嵌入带有创建的_id的文档中。 这里的问题是，在撰写本文时， BSON文档的大小限制为16 MB 。 达到此限制后，您的用户将无法再进行通信。 增加文档的大小还可能导致频繁的文档重定位 ，除非您使用MongoDB 3.0版中引入的新的WiredTiger存储引擎，否则这是一项非常昂贵的操作。

因此，我们需要一种更具可扩展性的方法。

这是我的方法：

用户：

{
  _id: "Kevin",
  email: "kevin@example.com"
  /* Put further user details as you see fit*/
}

信息：

{
  _id: new ObjectId(),
  from: "Kevin",
  /* You might want to have multi-person chats, hence the array */
  to: ["Matt"],
  ts: new ISODate(),
  message: "Hi, Matt!"
}

指数：

db.messages.ensureIndex({from:1,to:1,ts:1})

查询以重建用户收到的所有消息：

var user = "Matt"
db.messages.find({"to": user}).sort({ts:1})

现在，您可以遍历结果集并为找到的每个“发件人”打开一个聊天窗口。

查询以重建定义的聊天室

var user = "Matt"
var sender = "Kevin"
db.messages.find({"from": sender, "to":user}).sort({ts:1})

将按时间顺序给您凯文发送给马特的所有消息。 由于两个查询都应使用索引，因此它们应该非常快。 您可以使用.limit(x)仅查询发送给user的最后x条消息。

使用这种方法，您不需要人工的_id ，创建的索引使您可以高效地执行与参与者有关的每个查询，并且可以按顺序对消息进行排序。 因为每条消息都是单独保存的，并且不再更改，所以您可以存储几乎无限数量的消息并绕过文档重定位问题。