I'm using Firebase realtime database (NoSQL), And trying to figure out the best database design for my data.
My data is primarily about discounts, each affiliator introduces a number of discount offers on several stores.
So I have an affiliator_category which maybe banks, clubs or organisations. And each category contains a number of affiliators and each affiliator contains number of stores divided into store_category, each store has a number of offers.
And for the user side (the one who do the shopping). A users has a number of memberships in several affiliators, and a number of spendings he/she does.
I'm thinking of two ways to design the database.
The first one:
Each player is separate, has its own table (or node), for example, I have affiliators table that has a column for affiliator_category table row id. Basically I'm writing a normalized database.
The seconde way:
Is to denormalize the database. I have an affiliator_category node that's the parentof affiliators, which contains a number of stores. The data is lied out just like a normal JSON.
I'm searching for the advantage and disadvantage of both methods. The database is to be used for a mobile app.
So if I used the first method I'll have to query for the data on each node, and query for the related nodes by the unique id of the first node and so on.
If I used the second method (since i'm using a number of filters and search criteria on the app) I'll have to retrieve the parent node and do the searching by writing codes to iterate inside the returned object and accumulate results in an array and so on.
I don't know which is the best way to design the database, each method has its own advantage, the first one will result in less coding and more data consistency but lower performance, The second method will result in way more code, complicated object inspections and searching for values inside object fields. But i'll gain higher performance and scalability.
