我们说我有两个用户,"马特" &安培; "凯文&#34 ;. Matt想给Kevin发消息,通过点击聊天按钮向Kevin发送聊天框启动的直接消息,他发送消息并且Kevin收到消息。
我通过将发送它的人(马特)和收到该消息的人(凯文)并将其连接成身份证来生成聊天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;
所以我很好奇我怎么能把它设置得更好以便我的程序知道,好吧Matt和Kevin有聊天,所以如果Matt消息Kevin会拉他们的聊天或反之亦然,Kevin消息Matt和它得到相同的消息?
答案 0 :(得分:3)
按字母顺序排序:
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
最后,如果您的数据库支持关系或连接,您最好的选择是为每个聊天分离聊天表/集合,并在用户和聊天之间“连接”(或创建关系)。然后,当您下次加载时,连接将引导您进行与两个用户相关联的唯一聊天。
答案 1 :(得分:2)
我认为你的做法过于复杂。此外,您似乎希望将单个聊天消息嵌入到包含创建的_id
的文档中。这里的问题是在撰写本文时有一个16 MB size limit on BSON documents。达到此限制后,您的用户将无法再进行通信。增加文档的大小也可能导致频繁document relocations,除非您使用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})
现在,您可以遍历结果集并为您找到的每个“from”打开一个聊天窗口。
查询重建已定义的聊天
var user = "Matt"
var sender = "Kevin"
db.messages.find({"from": sender, "to":user}).sort({ts:1})
将按时间顺序向您发送由Kevin发送给Matt的所有消息。由于两个查询都应该使用索引,因此它们应该非常快。您可以使用.limit(x)
仅查询发送到user
的最后x条消息。
使用这种方法,您不需要人工_id
,创建的索引允许您有效地执行与参与者相关的每个查询,并且可以按顺序对消息进行排序。由于每条消息都是单独保存的,并且不再更改,因此您可以存储几乎无限数量的消息并绕过文档重定位问题。