This is pretty old, but when working on a firebase-enabled application, I often encountered similar problems.
.equalTo is more time-efficient (especially if one user owns a large number of elements). Although n + 1 subscriptions do not result in n + 1 network backlinks to the cloud, there is some measure of performance with so many open subscribers.
In addition, the .equalTo approach does not denormalize your data.
However, there is a question: when you want to protect data, the .equalTo approach may stop working at all.
To allow the user to call orderByChild ("user"). equalTo (user.uid), they must have read privilege for the "items" collection. This read permission is valid for the entire subdocument rooted in / items.
Summary If user1 fails to find out about user2 elements, you should use the BYOI approach (create your own index). This way you can verify that the user only reads the elements that are placed in their index.
Finally, a disclaimer :) I use firebase only for a short period of time, all I have is a few tests and documentation. If I am wrong, please correct me.
source share