Firebase数据库结构 - 需要建议 [英] Firebase database structure - need advice

问题描述

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

让我们从应用程序描述开始

< blockquote>

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

这是我的数据库结构的想法： / p>

 用户：
 user_id：121jhg12h12 
电子邮件：[e-mail]
名称：John Doe
 profile_pic_path：https：// ...。 
语言：en
 exp_points：1284 
朋友：[user_id] 
 books：[[book_id，status_current_page，start_date，finish_date]] 
徽章： [b] [b] 
 $ b书籍：
 book_id：3213jhg21 
标题：为谁而鸣钟
作者：海明威
语言：en
 pages_count：690 
 ISBN：21hjg1
年：2007 
 
徽章：
 badge_id：213hg12 
名字：伟大的读者！ 
 image_path：https：// ...。 
  

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

我想通过问这个问题来获得一个明确的答案，如果我的方法是正确的，或者我应该改变数据库中的东西结构来磨练未来的可伸缩性和一般性能。注意，我意识到这个问题可能被认为更适合于代码审查论坛，但是正如你所知道的，很少有人会在那里回答，特别是像firebase数据库结构这样的狭窄主题。

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

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

2）一个朋友列表是存在的，你也需要一个朋友请求系统。为此，我建议创建一个名为outgoing_requests的密钥，即所有发送给其他用户（w / userID）的朋友请求仍然不完整。另外，创建一个名为incoming_requests的密钥，其中包含其他用户向您发送的请求。这是你将用来创建一个朋友请求页面，并允许用户接受或拒绝。这造成了一些JSON规则的复杂性。我可以这样做：

• outgoing_requests：可以由用户自己写（取消请求）或者具有请求标识的用户（接受或拒绝请求）


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



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



  books：
 book_id：
 lastopened_date：
状态：
 current_page：
 start_date：
 finish_date：
  

然后在状态中，存储完整或不完整。 lastopened_date&如果不完整，将使用current_page。 start_date&如果完成，将使用finish_date。然后，可以很容易地查询完成的书籍的完成日期，以及根据上次打开的日期查询未完成的书籍。
徽章可以像这样存储：



 徽章：
 badge_id：
 get_date：
  

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


I know this question might be seen as an opinion-based one, however I think it's worth to discuss the way to properly structure database. I work on iOS app in Swift and decided to use firebase as my backend service

Let's start with the app description

The app aims to provide tracking and social features to book reading experience, as well as create books database. User adds book, fill basic info like title, author, language, number of pages etc. Next, this book is visible on the list in app, where user can easily access the book info and save the information on which page he/she recently ended reading. After a book is marked as read, user obtains experience points and badge. Ultimately, the user is going to be able browse friend's achievements, create a leaderboard etc.

This is my idea of database structure:

  Users:
    user_id:121jhg12h12
      email: "[e-mail]"
      name: "John Doe"
      profile_pic_path: "https://...".
      language: "en"
      exp_points: 1284
      friends: [user_id]
      books: [[book_id, status, current_page, start_date, finish_date]]
      badges: [[badge_id, get_date]]

  Books:
    book_id: 3213jhg21
      title: "For whom the bell tolls"
      author: "Ernest Hemingway"
      language: "en"
      pages_count: 690
      ISBN: "21hjg1"
      year: 2007

  Badges:
    badge_id:213hg12
      name: "Great reader!"
      image_path: "https://...".

I used pseudo code filled with some dummy data instead of JSON format to make it more readable, if I failed, let me know.

What I would like to achieve by asking this question is to obtain an explicit answer if my approach is right, or should I change something in database structure to hone future scalability and general performance.

Note that I'm aware of the fact that this question may be considered as more suitable for code review forum, but as you know, rarely anybody answers there, especially in such narrow topic like firebase database structure.

thanks in advance

解决方案

In my opinion, your book and badges data models look totally fine. They will be public to any user in the app and do not store any complex data.

Now to get to the user objects: 1) For this type of app, where user interactions will be occurring, you will most likely want to protect the privacy of your users by not storing their email (since the user object has to be readable by others). The email will already be embedded in the user's authentication token, so saving it into the database as well is redundant and reduces privacy. If you really wanted to save it, you could make a new object named "user_private" and have it only be readable by the user himself.

2) For an app where a friends list is present, you will also need a system of friend requests. To do this, I would suggest creating a key named "outgoing_requests", that is all the friend requests you have sent to other users (w/ userID) that are still incomplete. Also, create a key named "incoming_requests", that contains requests other users have sent you. This is what you would use to create a friend requests page and allow a user to accept or deny. This creates some complexities with the JSON rules. I would lay it out like this:

• outgoing_requests: writable by user himself (cancel request) or by the user who has the id of request( accept or deny request)
• incoming_requests: writable by user himself (accept or deny) or by user who has id of request (cancel)
• friends_list: writable if new entry and id is part of incoming requests, or deleting and this is my user

3) You will also likely be querying your user's books based on timestamps. Therefore, I would lay it out so this is easy to accomplish (an array won't work because the user may start reading a book they havent opened in a while and the ordering will be mixed up). You could store user's books like this:

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

Then, in status, either store "complete" or "incomplete". "lastopened_date" & "current_page" will be used if incomplete. "start_date" & "finish_date" will be used if complete.Then it is easy to query for finished books by what date they were finished, and query for unfinished books by what date they were last opened. Badges can be stored like this:

badges:
  badge_id:
    get_date:

Storing the books & badges like this makes it much easier to query based on timestamps. This is everything I can think of for now. Let me know if you have any questions.

这篇关于Firebase数据库结构 - 需要建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！