UPDATE: 现在有一个关于结构化数据的文档。另外，请参阅这篇优秀的文章NoSQL 数据结构.
与 RDBMS 不同，分层数据的主要问题是它很容易嵌套数据，因为我们可以这样做。通常，尽管缺少连接语句和查询，您还是希望在某种程度上规范化数据（就像使用 SQL 所做的那样）。
你也想非规范化在需要考虑读取效率的地方。这是所有大型应用程序（例如 Twitter 和 Facebook）都使用的技术，尽管它违反了我们的 DRY 原则，但它通常是可扩展应用程序的必要功能。
这里的要点是，您希望在写入方面下功夫，以使读取变得容易。将单独读取的逻辑组件分开（例如，对于聊天室，如果您希望稍后能够迭代组，请勿将消息、有关房间的元信息以及成员列表全部放在同一个位置）。
Firebase 的实时数据和 SQL 环境之间的主要区别在于查询数据。由于数据的实时性（它不断变化、分片、协调等，这需要一个更简单的内部模型来检查同步客户端），因此没有简单的方法可以说“在 X = Y 处选择用户”
一个简单的例子可能会让你处于正确的心态，所以这里是：
/users/uid
/users/uid/email
/users/uid/messages
/users/uid/widgets
现在，由于我们处于分层结构中，如果我想迭代用户的电子邮件地址，我会执行以下操作：
// I could also use on('child_added') here to great success
// but this is simpler for an example
firebaseRef.child('users').once('value')
.then(userPathSnapshot => {
userPathSnapshot.forEach(
userSnap => console.log('email', userSnap.val().email)
);
})
.catch(e => console.error(e));
这种方法的问题是我刚刚强制客户端下载所有用户的messages and widgets也。如果这些东西都没有数以千计，那也没什么大不了的。但对于 10,000 个用户（每个用户有超过 5,000 条消息）来说，这是一个大问题。
因此，现在分层实时结构的最佳策略变得更加明显：
/user_meta/uid/email
/messages/uid/...
/widgets/uid/...
在这种环境下非常有用的另一个工具是索引。通过创建具有某些属性的用户索引，我可以通过简单地迭代索引来快速模拟 SQL 查询：
/users_with_gmail_accounts/uid/email
现在，如果我想为 Gmail 用户获取消息，我可以这样做：
var ref = firebase.database().ref('users_with_gmail_accounts');
ref.once('value').then(idx_snap => {
idx_snap.forEach(idx_entry => {
let msg = idx_entry.name() + ' has a new message!';
firebase.database().ref('messages').child(idx_entry.name())
.on(
'child_added',
ss => console.log(msg, ss.key)
);
});
})
.catch(e => console.error(e));
我在另一篇关于非规范化数据的 SO 帖子中提供了一些详细信息，所以也检查一下。我看到 Frank 已经发表了 Anant 的文章，所以我不会在这里重申，但这也是一篇很棒的文章。
