实时数据库

实时数据库可以让您将数据存储为一个大型的在线结构变量。

注意

如果您不确定是否应该使用Firestore还是实时数据库，请阅读官方比较文档。

与结构变量的比较

数据都存储在一个JSON树中，这与结构变量是相似的。但有一些关键区别：

• 访问子节点

与GDevelop变量不同，在GDevelop中，您通过<structureVariable>.<childVariableName>获取子变量，在实时数据库中，您使用斜杠进行获取：<structureVariable>/<childVariableName>。这意味着，对于动态访问，您应该将路径名称编写为"structure/" + VariableString(dynamicVariableAccess) + "/specificProperty"，而不是GDevelop结构中的编写方式：Variable(structure[VariableString(dynamicVariableAccess)].specificProperty)

• 子节点嵌套

在GDevelop中，子节点的嵌套深度没有固定限制，但是实时数据库不允许嵌套超过32级。

数据结构化

您应该以尽可能少的嵌套方式来设计数据结构，因为嵌套数据可能会在一些情况下引起问题：

• 检索数据。每当从服务器检索数据时，您也会下载所有嵌套数据。如果数据量很大，可能会花费时间并导致延迟。
• 权限继承。如果您制定了允许访问某个字段的安全规则，则所有嵌套字段将被赋予相同的访问级别，无法为单个嵌套字段覆盖访问权限。
• 嵌套限制。如果嵌套数据过多，您可能会沦为持续支持游戏的旧版本，但又要保持结构的一致性。然而，如果达到最大嵌套级别（32），则无法添加新的嵌套属性，因此无法在不重新设计数据库结构的情况下保持一致的结构，这意味着失去对所有旧版本的支持以及大量的工作。

除了尝试远离嵌套，您应该可以根据自己的意愿设计数据库的结构。

有关实时数据库中数据建模的更多信息，请阅读数据结构指南。

访问调节

您可能不希望每个人都可以写入所有内容。否则，每个人都可以修改其他人的数据！为了选择谁可以访问什么，以及如何访问，Firebase有规则系统。它与Firebase身份验证相互操作，因此您可以编写此规则，仅允许经过身份验证的玩家写入数据库的authonly变量：

{   "rules": {     "authonly": {       ".read": true,       ".write": "auth != null"     }   } }

您也可以拥有一个包含所有用户的变量，并且对于每个子节点（以用户uid命名），将其权限作为映射。例如，在这里，您可以允许每个具有"verified"权限的用户访问名为他们用户ID的自己的变量的userdata变量，每个经过身份验证的用户读取globaldata变量，每个管理员写入所有变量：

{   "rules": {     "userdata": {       "$uid": {         ".read": "$uid == auth.uid",         ".write": "auth != null && (root.child('permissions').child(auth.uid).child('verified').val() == true && $uid == auth.uid) || root.child('permissions').child(auth.uid).child('admin').val() == true"       }     },     "globaldata": {       ".read": "auth != null",       ".write": "auth != null && root.child('permissions').child(auth.uid).child('admin').val() == true"     },     "permissions": {       "$uid": {         ".read": "auth != null",         ".write": "auth != null && root.child('permissions').child(auth.uid).child('admin').val() == true"       }     }   } }

要详细了解如何编写规则，请阅读语法指南。