0

I'm working on a website for collecting unpaid invoices. A visitor is able to place an order (provide his/her company data and upload one or more unpaid invoices) and pay for the service BEFORE making a user account.

This means that I have to add the uid afterward. Normally this isn't a big deal but I'm duplicating the invoice and company data to a file node.

Because of that, firebase has to loop through all the invoices nodes to check where the uid is matching the current user id when a user wants to fetch their own invoices. 

invoices
   invoice 1
      general
         uid: 'uid-123'
         orderid: 'order-1234'
      documents
      creditor
      ...
   invoice 2
      general
         uid: 'uid-123'
         orderid: 'order-1234'
      documents
      creditor
      ...
   invoice 3
      general
         uid: 'uid-543'
         orderid: 'order-3434'
      documents
      creditor
      ...

Is this approach/structure ok (I don't want a huge bill in a few months because firebase has to loop through 100 - 1000 - 5000 invoice nodes every time) or is there a way around to become the following structure which seems better/faster.

invoices
   uid 1
      invoice 2
      invoice 4
      invoice 5
   uid 2
      invoice 1
      invoice 3
      invoice 8
Thore
  • 1,918
  • 2
  • 25
  • 50
  • Sorry, there is really way too much information in your post to efficiently answer. From a quick scan it seems you're asking if it's OK to duplicate some data (the invoice ID) to make querying that data easier/faster. The answer to that is yes: data duplication is quite normal in NoSQL databases. See https://firebase.googleblog.com/2013/04/denormalizing-your-data-is-normal.html, https://stackoverflow.com/questions/30693785/how-to-write-denormalized-data-in-firebase and https://firebase.google.com/docs/database/web/structure-data#fanout – Frank van Puffelen Jan 05 '19 at 14:30
  • For an introduction to NoSQL data modeling, read [NoSQL data modeling](https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/) and watch [Firebase for SQL developers](https://www.youtube.com/playlist?list=PLl-K7zZEsYLlP-k-RKFa7RyNPa9_wCH2s). – Frank van Puffelen Jan 05 '19 at 14:31
  • @FrankvanPuffelen I'm sorry, I was a bit too enthusiastic :-) I've shortened the question and I hope it's clearer now. The question is really simple I guess. Is a database structure where a user-id or order-id (general: something to compare with) is used to compare the node with a frontend parameter ok and scalable instead of using the compare-parameter as key? – Thore Jan 05 '19 at 15:00
  • Sounds fairly normal. See my answer to the second link I gave before on approaches on updating denormalized data. You might also want to consider signing the users in with [anonymous authentication](https://firebase.google.com/docs/auth/web/anonymous-auth), to ensure they already have a UID before they explicitly sign in. That means you'll have to implement [account linking](https://firebase.google.com/docs/auth/web/account-linking), but won't have to update the denormalizing data anymore. – Frank van Puffelen Jan 05 '19 at 15:23

0 Answers0