firebase realtime schema design

Question

i have two set of entities in my firebase realtime schema. Called Orders and customers.

so far i was not actually relating them in my app but was just showing them related. the current schema looked like:

{
"orders" : [ 
             {"id" : 1, "name": "abc", "price": 200, "customer": "vik"}
           ],
"customers" : [
                 {"cust_id" : "10", "name" : "vik", "type": "existing"}
               ]
}

so i have a orders list page showing all the orders in a table which i get firing /orders.json

But practically, instead of having the customer name directly in the orders i should have cust_id attribute as that is the key.

That naturally makes it a standard relational schema where i will be free to change customer attributes without worrying about mismatch in orders.

However, the downside i see right away is that if i have say 20 orders to show in the order list table then instead of 1 i will end up firing 21 rest calls (1 to get order list and 20 to fetch customer name for each of the order)

What are the recommendations or standards around this ?

Answer 1

Firebase is a NoSQL database. So the rules of normalization that you know from relational databases don't necessarily apply.

For example: having the customer name in each order is actually quite normal. It saves having to do a client-side join for each customer record, significantly simplifying the code and improving the speed of the operation. But of course it comes at the cost of having to store data multiple times (quite normal in NoSQL databases), and having to consider if/how you update the duplicated data in case of updates of the customer record.

I recommend reading NoSQL data modeling, watching Firebase for SQL developers, and reading my answer on keeping denormalized data up to date.