【问题标题】:How to structure chat application using Firebase Realtime Database to incorporate user data?如何使用 Firebase 实时数据库构建聊天应用程序以合并用户数据?
【发布时间】:2022-02-01 10:39:42
【问题描述】:

截至目前,我正在使用 Firebase 实时数据库将聊天功能作为我正在开发的应用程序的一部分。我似乎遇到的唯一问题是弄清楚如何包含用户的数据(个人资料、用户名、生日等),这样如果用户点击聊天,他们就可以无缝地转到用户的个人资料页面而无需从后端获取更多数据。这是我在 Firebase 实时数据库中为此使用的当前结构:

$chats
  $chatId
    id
    users
      0: some user id
      1: some user id
    lastMessage

$userChats
  $userId
    $chatId: true

$users
  $userId
    user info here

就我而言,我想知道的是,将每个用户的所有用户数据复制到 users 数组中的每个聊天中是否更有意义,或者我是否应该只使用引用 userId 并在单独的请求?

考虑到我主要将我的用户存储在一个单独的 PostgreSQL 数据库中,我想知道我是否可以对该数据库进行单独的查询,甚至不必担心将用户存储在实时数据库中(考虑到我必须为每个用户喜欢计数器)。

【问题讨论】:

  • 所有听起来都是有效的选择,并且是正确的考虑。您在此处的答案中寻找什么(注意什么是有意义的通常是相当主观的)?
  • @FrankvanPuffelen 我希望找到一个最容易扩展的解决方案。在我看来,在我从 Firebase 获得每次聊天后,从 Postgres 数据库中查询用户会很容易,但不确定这会如何影响聊天的整体“实时”感觉。我只觉得将用户包含在 Firebase 中对离线目的有意义,但我的应用目前不打算支持它。
  • 这个问题很难回答,而且它超出了我们在 SO 上所做的工作,因为这里的问题是特定于编码的。提供代码,问题,我们来看看。你真的在问一个设计问题。对我来说,我会将所有用户存储在 Firebase 中,因为它可以很好地处理身份验证。此外,“从后端提取数据”是 Firebase 所做的。它通常是少量的数据,并且是“即时的”——你试过了吗?如果没有,你应该!虽然 NoSQL 的非规范化是正常的,但它可能会过度,当数据集很小时,通常没有理由这样做。
  • @Jay 我想我正在尝试确定将用户数据包含在聊天对象中还是仅通过其 ID 引用它是否合理。在我看来,我只是犹豫是否要存储参考,因为我必须为每个单独的用户进行查询。
  • 我必须为每个单独的用户进行查询 并且....有什么问题?这是常见的做法。我们无法知道您何时/为什么需要在您的应用程序中执行功能的上下文是什么。例如如果用户点击聊天,他们就可以无缝地转到用户的个人资料页面 - 这是很正常的事情,对吧?如果在用户单击之前不使用它,为什么要加载一堆用户数据。您可能需要用户名(在聊天中显示),然后是对其用户节点的引用。但如前所述,这是一个我们无法回答的设计决策。

标签: ios swift firebase firebase-realtime-database


【解决方案1】:

如果您总是要在聊天的同时获取用户数据,那么您应该将它们存储在一起。无需拨打多个电话。

但是,如果您要单独获取用户数据和/或会话,我建议您单独存储用户数据,而不是在会话中。

此外,如果您真的想要“即时”的感觉(超越已经“实时”的数据库性能),您还可以在打开特定聊天后立即在后台获取用户数据。这样一来,如果用户点击查看个人资料,则该个人资料已经被获取,并会提供您正在寻找的“即时”体验。

另外,您必须记住,无论调用多少次,实时数据库都会对传输的数据量收费(与 Firestore 对查询次数收费相反),因此单独存储数据不会增加费用与一个查询相比,在您不需要两个数据集的情况下实际上可以节省资金。

【讨论】: