0

A newbie here. I need help regarding Firebase sub collection referencing in a structured way where a user can select and pass information through sub collection.

=> Tournaments => Cities => Cairo => Year => High Goal => Team A

That goes like this from the root I have a list of cities let’s say

 1. Cairo 
 2. Alexandria
 3. Sixth October

I want to keep record of tournaments hosted each year by these cities based on years. Let’s say a.

 1. 2019    
 2. 2018
 3. 2017

Each year there are 3 different competed cups let’s say

 1. High goal   
 2. Medium goal
 3. Low goal

Every competed cup has teams that participate in the tournament

 1. Team A  
 2. Team B
 3. Team C

I have added a visual representation of the app designed in adobe XD.

Abbakayy
  • 1
  • 1
  • 1
  • 1
    what exactly you want to do? – Srilal Sachintha Jun 29 '20 at 14:34
  • Hi I have four different pages that i want each to contain documents based on user input. Based on the structure provided on the question. A user should be able to choose an option for example Cairo => it will take the user to another page where the user will select (from a sub collection) which year to view. after the user select the year (Lets say 2019), another page will be displayed containing a list of subcollection of the different cups (i.e High Goal, Low Goal, ..) then again the user can choose an option that will take him to the team list and selection. hope it all make sense. – Abbakayy Jun 29 '20 at 17:45
  • I have an Adobe XD design of may intent but I'm not yet able to add a picture on SO – Abbakayy Jun 29 '20 at 17:46

1 Answers1

1

Data modeling for NoSQL databases depends as much on the use-cases of your app as it depends on the data that you store. So there is no "perfect" data model, nor are there nearly as many best practices (or normal forms) for NoSQL databases are there are for relational data models.

Firestore (which you seem to be looking to use), offers a few tools for modeling data:

  • The discrete unit of storage is called a document. Each document contains fields of various types, including nested fields, and a document can be up to 1MB in size.
  • Documents are stored in named collections.
  • You can nest collections under a document, and build hierarchies that way.
  • Each document has a unique path of the form /collection1/docid1/collection2/doc2 etc.
  • To write to a document, you must know its exact path.
  • You can query a collection for a subset of the documents in there.
  • You can query across all collections with the same name, no matter their path in the database.
  • The performance of queries depends solely on the number of documents you retrieve, and not on the number of documents in the collection(s).

There are probably quite a few more rules, but these should be enough to get you started.

I typically recommend writing a list of your top 3-5 use-cases, and determining what reads/queries you need for that. With those queries, you can then start defining your data model, and implementing your application code.

Then each time you add a use-case, you figure out how to read/write the data for that use-case, and potentially change/expand the data model to allow for the new and existing use-cases. If you get stuck when adding a specific use-case, report back here and we can try to help.

Some good additional material to get started:

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807