Firebase存储数据最佳实践 [英] Firebase storing data best practices

问题描述

我正在开发一款使用Firebase的应用。

I'm developing an app which uses Firebase.

您知道存储数据的最佳方式吗？

Do you know the best way to store data?

我已阅读他们关于结构化最佳实践的文档数据，但不提供有关ID的建议。

I have read their documentation on best practice for structuring data but doesn't offer advice on ids.

使用我的应用程序，一旦用户注册其用户信用，就会添加并为其创建个人资料。

With my app once a user registers their user credientials are added and it creates a profile for them.

这将存储到'个人资料'文档中，如下所示：

This stores into a 'profile' document as follows:

profile
      -> uniqueId (generated by Firebase)
                 -->  uid (unique Firebase generated uid)
                 -->  email
                 -->  password

然而，在我的下一个名为'settings'的文档中，这个设置不同......

However on my next document called 'settings' this is set differently...

唯一ID不存在，它使用这样的uid

The unique id doesn't exist and it uses the uid like this

settings
        ->  uid (Firebase user Id - not a unqiue id)
               -->   setting1
               -->   setting2
               -->   setting3

因此，就最佳做法而言，让Firebase生成唯一ID然后拥有uid？喜欢个人资料文件？

So in terms of best practice is it not better to have Firebase generate a unique id and then have the uid? Like the profile document?

或者我这样做了吗？

Firebase文档建议保持结构平整尽可能。所以我的想法是。但后来我担心索引。是否会出现性能问题？

Firebase documentation recommend keeping the structure as flat as possible. So my thoughts are it is. But then I am concerned about indexing. Would there be a performance issue with that?

此外，如果最好有这样的设置文档......

Also if it is better to have the settings document like this...

settings
         -> uniqueId
                -->     uid (user Id)
                -->     settings1
                -->     settings2

然后，它不会使特定userId访问设置的方式变得复杂。并且不应该将配置文件设置为与设置相同的方式吗？

Then does it not over complicate how settings are accessed for a specific userId. And shouldn't profile be set the same way as settings?

可能没有更好的选择，但我有兴趣听到想法。

May be there isn't a better option but I'd be interested to hear thoughts.

非常感谢

推荐答案

uid 是 a唯一的id因此在/ users节点的情况下使用它们的uid作为父节点名称是很好的。

The uid is a unique id so it's great to use their uid for parent node names in cases like a /users node.

此外，如果每个用户都有自己的设置，那么它很酷包括那些进入/ users / uid / node的那些。

Also, if each user has their own settings, then it's cool to include those into the /users/uid/ node.

'更平坦更好'是座右铭但有时候扁平化可能实际上使事情过于复杂。在这种情况下，用户登录并读取其设置。完成。您不会查询它或进行任何类型的交叉引用查找，因此请将其与其他用户数据保持一致。

'Flatter is better' is the motto but there are times when flattening may actually overcomplicate things. In this case, a user logs in and their settings are read. Done. You won't be query-ing it or doing any kind of cross reference lookups so just keep it with the other user data.

一般情况下，您的方法是正确的：

In general your are on the right track:

使用自动创建的ID是一种很好的做法 - 这允许您取消节点名称与其包含的数据的关联。

Using auto created id's is good practice - this allows you to disassociate node names from the data it contains.

像电子邮件地址和人名这样的东西，实际上任何可能改变的东西都不是最好的节点名称，因为它们可能会在你的结构中的其他200个地方被引用，如果电子邮件地址发生变化，例如，你将不得不寻找200个地方并进行更新。 （电子邮件地址也有特殊字符，因此您必须按摩它们才能使它们正常工作。）

Things like email addresses and people's names, and really anything that could change are not the best node names, as they may be referenced in 200 other places in your structure and if the email address changes, for example, you'll have to seek out 200 places and perform updates. (email addresses have special characters as well so you have to massage them to make them work anyway.)

使用自动生成的节点名称，您可以更改一次。

With a auto-generated node name, you change it once.

这篇关于Firebase存储数据最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！