Question

我知道这个问题可能被视为基于意见的问题，但我认为讨论正确构建数据库的方法是值得的。我在Swift的iOS应用程序上工作，并决定使用firebase作为我的后端服务

让我们从应用说明开始

该应用程序旨在为图书阅读体验提供跟踪和社交功能，以及创建图书数据库。用户添加书籍，填写标题，作者，语言，页数等基本信息。接下来，该书在应用程序列表中可见，用户可以轻松访问书籍信息并保存最近他/她的页面信息读完了。将书籍标记为已读后，用户将获得经验值和徽章。最终，用户将能够浏览朋友的成就，创建排行榜等。

这是我对数据库结构的看法：

我使用填充了一些虚拟数据而不是JSON格式的伪代码来使其更具可读性，如果我失败了，请告诉我。

我想通过提出这个问题来获得一个明确的答案，如果我的方法是正确的，或者我应该改变数据库结构中的某些东西来磨练未来的可扩展性和一般性能。

请注意，我已经意识到这个问题可能被认为更适合代码审查论坛，但正如您所知，很少有人在那里回答，特别是在像firebase数据库结构这样的狭隘主题中

提前致谢

Answer 1

在我看来，你的书和徽章数据模型看起来完全没问题。它们将公开给应用程序中的任何用户，并且不存储任何复杂的数据。

现在转到用户对象： 1）对于这种类型的应用程序，在用户交互将发生的情况下，您很可能希望通过不存储其电子邮件来保护用户的隐私（因为用户对象必须是其他人可读的）。该电子邮件已经嵌入在用户的身份验证令牌中，因此将其保存到数据库中也是多余的，并且会降低隐私。如果你真的想保存它，你可以创建一个名为＆＃34; user_private＆＃34;并且只有用户自己才能阅读。

2）对于存在朋友列表的应用，您还需要一个朋友请求系统。为此，我建议创建一个名为＆＃34; outgoing_requests＆＃34;的密钥，这是您发送给其他用户（w / userID）但尚未完成的所有朋友请求。此外，创建一个名为＆＃34; incoming_requests＆＃34;的密钥，其中包含其他用户发送给您的请求。这是您用来创建朋友请求页面并允许用户接受或拒绝的内容。这会使JSON规则产生一些复杂性。我会这样说出来：

outgoing_requests：用户自己可写（取消请求）或具有请求ID的用户（接受或拒绝请求）
incoming_requests：用户自己可写（接受或拒绝）或有请求ID的用户（取消）
friends_list：如果新条目和ID是传入请求的一部分，或者是删除而且这是我的用户，则可写

3）您也可能会根据时间戳查询用户的图书。因此，我会把它放在一边，这样很容易实现（一个数组不会起作用，因为用户可能会开始阅读他们暂时没有打开的书，而且排序会混淆）。您可以像这样存储用户的书籍：

books:
  book_id:
    lastopened_date:
    status:
    current_page:
    start_date:
    finish_date:

然后，在状态中，要么存储＆＃34;完成＆＃34;或＆＃34;不完整＆＃34;。＆＃34; lastopened_date＆＃34; ＆安培; ＆＃34; CURRENT_PAGE＆＃34;如果不完整将被使用。＆＃34;起始日期＆＃34; ＆安培; ＆＃34; finish_date＆＃34;如果完成，将使用它。然后很容易查询完成的书籍完成的日期，并在上次打开它们的日期查询未完成的书籍。徽章可以这样存储：

badges:
  badge_id:
    get_date:

存储书籍和这样的徽章使得基于时间戳查询变得更加容易。这是我现在能想到的一切。如果您有任何疑问，请告诉我。

Firebase数据库结构 - 需要建议

1 个答案: