CODEWITHSUNDEEP
databasefirebasegoogle-cloud-firestorestructure
showtime
showtime

Reputation: 1462

Best way of structuring documents in Cloud Firestore (NoSQL databases)?

I am trying to implement a Firestore Cloud DB but I am new to NoSQL databases.

I want to know whats the best way of arranging these sets into collections/documents:

I have restaurants which have different foods and reservations. What would be the best approach to structure these sets of data into Firestore DB?

Is this a right approach:

Restaurant1 (Collection)
----> Foods (document) 
----> Reservations (document)

Upvotes: 0

Views: 667

Answers (3)

Alex Mamo
Alex Mamo

Reputation: 138814

According to your comment:

the restaurant´s management should be able to see his reservation together with other reservations from other clients, in a list. And each client should be able to see his history of reservations as well.

I'll try to provide you a schema that can help you get that data very easily.

Firestore-rrot
   |
   --- users (collection)
   |    |
   |    --- uid (document)
   |    |    |
   |    |    --- type: "manager"
   |    |
   |    --- uid (document)
   |         |
   |         --- type: "client"
   |
   --- reservations (collection)
        |
        --- reservationIdOne (document)
        |       |
        |       --- reservedBy: "uid"
        |       |
        |       --- date: September 21, 2019 at 1:15:02 PM UTC+3
        |
        --- reservationIdTwo (document)
                |
                --- reservedBy: "uid"
                |
                --- date: September 21, 2019 at 1:18:42 PM UTC+3

Using this schema, you can simply query the database to get all users or specific users (manager or clients). You can also get all reservations by adding a reference on reservations collection. If you want to get the reservation only of a single type (manager or client), you should use a query that might look like this:

db.collection("reservations").whereEqual("type", "manager");

As you can see, I have also added a date property so you can easily sort them descending (last reservation first).

Upvotes: 2

Thingamajig
Thingamajig

Reputation: 4465

I think storing Foods and Reservations as top level collections will ultimately yield you more flexibility later on.

It's easy enough to take a restaurantID and stick it in the each document in those collections, so I don't personally think you should nest them in the Restaurants collection. It's a personal preference from working with a lot of nested collections.

I think the optimal structure is:

Restaurants (collection)
--- Name: Chipotle
--- ID: restaurant1
--- Foods: [{ Name: foodItem1 }, { Name: foodItem2 }]

Foods (collection)
--- Name: foodItem1
--- Ingredients: abc
--- Nutrition Facts: xyz

Reservations (collection)
--- User: user1
--- Restaurant: { id: restaurant1, name: Chipotle }
--- Time: 3pm

Users (collection)
--- ID: user1

What you'll notice is there is some redundant info. This is good so if you request all reservations, you'll get the restaurant's name and ID, etc. stuff you would likely want. You will find you'll want to store data multiple times and this to me feels like a good structure for it.

With this structure you can very easily just call:

All reservations by user X or All foods meeting nutrition limits of Y

Instead of a collectionGroup query which would call for all restaurants' sub collection list of reservations. You won't always want to query your reservations by restaurant, maybe you want to pull by user or time, etc.

Upvotes: 3

petomalina
petomalina

Reputation: 2140

It really depends on the use-case you are trying to solve, as you should be optimizing for specific queries on those models.

I recommend watching these videos to get a better idea:

Upvotes: 1

Related Questions