I’m new to NoSQL so I need an opinion on how the flow on how noSQL works.
I’m trying to make an employee rewards website where users can use points to redeem rewards such as vouchers, and coupons, etc.
Therefore, what I imagine is there will be a user collection and a rewards collection where a document in a users collection will store basic user information as well as user points. Rewards collection will store document that contains the info of certain rewards such as the points to redeem and their quantity etc.
Is it the best solution to create an inventory for users to store the rewards bought from the rewards page (from the rewards collection) in another collection called userRewards which calls the rewardsID from the rewards collection and the user collection will have another entity called userInventory where it calls the userRewardsID? So will the user Inventory entity save the userRewardsID as an array, because some say it is not good practice?
This is how I imagine the flow
User Rewards UserRewards
---- ----- ---------------
ID ID ID
Name Name RewardsID
Phone Quantity ClaimStatus
Email Points
UserInventory : UserRewardsID
2
Answers
You want to UNLEARN what you know about SQL.
NoSQL is not SQL. SQL is the evil twin of NoSQL.
You do NOT want to use "references" and "JOINs" in NoSQL. Instead…embrace DATA DUPLICATION (i.e. data DEnormalization).
Here’s an article on that.
In the NoSQL world, we are structuring a database according to the queries that we want to perform. So according to your last comment:
Then I recommend you structure the database like this:
Having such a structure, you can create a collection reference that points to the
rewards
sub-collection so you can get all the rewards that correspond to a specific user. Besides that, please also note that there are no JOINS in Firestore.