相当于解析云代码的服务器端自定义操作：
Parse有可能编写云代码。据我所知，Firebase没有在控制台上提供任何工具。
实现这一点的唯一方法是使用Firebase API实现web服务，并监控节点的更改，并在我自己的服务器上实现云代码。
- A-这是正确的吗
服务器端规则：
Firebase的遗留文档描述的规则似乎仅限于决定哪个用户可以读/写以及验证。
{
"rules": {
"foo": {
// /foo/ is readable by the world
".read": true,
// /foo/ is writable by the world
".write": true,
// data written to /foo/ must be a string less than 100 characters
".validate": "newData.isString() && newData.val().length < 100"
}
} }
在Parse上，规则的复杂性更大。程序员能够创建函数来执行自定义操作。
了解Firebase按原样设计的原因：
我想Firebase上没有这种复杂性的原因是，基于节点的数据库可能比基于表的数据库更复杂，如果开发人员使用web api和自定义服务器应用程序完全控制这一点会更好。
- B-这是正确的吗
实时数据库限制：
在我看来，使用像Firebase这样的实时数据库时的主要限制是，一旦您获取一些实时数据，如果数据包含双向冗余，则在一个节点上触发的事件不会传播到包含冗余信息的节点。
例如，如果用户节点具有密钥id(在用户节点的同一级别的不同节点的id)，并且如果我在表视图上显示用户具有的密钥列表以检测密钥列表是否已更改，我需要监听密钥节点中的更改(而不仅仅是用户节点中的改变)。
-C：这是正确的吗
这个问题有点模糊，因为没有用例，但根据注释，到此为止。
A) 是的，也许吧。是的，没有服务器端逻辑(代码方面)。也许，这取决于你想做什么。
B) Firebase规则非常灵活；规则可以限制谁可以访问数据、读/写访问、什么类型的数据、数据类型、数据位置等。它既不比"基于表的"复杂，也不比"表的"更复杂。这只是验证、验证和存储数据的一种不同方式。
仅供参考：Parse是由MongoDB支持的，MongoDB是一个基于文档的NoSQL数据库(它不是基于表的)。在后端，Parse数据的存储方式类似于Firebase。(实际上是BSON)。他们的前端实现是围绕JSON结构的对象，这给人的感觉是它比Firebase更像表，这导致了在PFobject之间建立关系的直接能力。
C) 不可以。您可以观察任何节点的变化。在您的示例中，您可能应该将keys节点作为一个独立于/user节点的节点，并让用户观察/keys节点。
为了进一步扩展，数据不一定需要是冗余的，但它可以是。你只需要观察你感兴趣的特定数据的变化。
假设每个用户都有一个/users节点和/foldite_food节点。如果你的用户界面显示了一个用户列表，其中一个用户更改了他们最喜欢的食物，你其实并不在乎——你只是对用户列表感兴趣。因此，您将观察/users节点，而不是/foldite_food节点。