问题
I am developing an app that will offer the possibility to filter the users you search (gender, age, location, ...). I want to make this fast and as cheaper as possible, so I have decided to store my data as a n-ary tree, just something like this:
----- Users -----
Root Node: Gender (male or female)
-male
--country (nodes: USA, UK, Spain, Germany, France, Italy, ...)
---age (nodes: 18, 19, 20, 21, 22, ..., 60)
->user (leaf nodes)
-female
--country (nodes: USA, UK, Spain, Germany, France, Italy, ...)
---age (nodes: 18, 19, 20, 21, 22, ..., 60)
->user (leaf nodes)
I think that structuring the database like this will reduce the amount of data, as I don't have to store the gender, country, and age as field in the last documents... But I don't know if this is a bad practices in the NoSql world, or if this will negativily affect the performance (velocity).
Any ideas about if this is a good structure? Or should I store all this properties in every user document and use the "where" query clausure? Thank you.
回答1:
In your scenario you want to filter on 3 attributes (gender, country and age) and I think it could work if all three attributes are provided.
If one of the three is missing you could use denormalization to replicate data on multiple collections, but since you want it cheap I presume you don't want to increase on the storage usage.
Another option would be to store them all inside a single user collection and query with where conditions taking advantage of indexing. The indexes are created on you behalf and they are the reason Firestore is so fast.
来源：https://stackoverflow.com/questions/63424992/firestore-nosql-database-structure-as-a-n-ary-tree