so as you recall from our last video there are a number of rules governing how cloud firestore works that all play a part in how you should structure your data and while it's fine to talk about these rules in theory I think sometimes it's better if we can put these in the context of some real-world or close to real world examples so come on with me let's figure out the best way to structure our data on this episode of get to know cloud firestore [Music] so the purposes of this video let's keep pretending that I've
got this great restaurant review app that I'm powering through cloud firestore maybe it's got a search page where you can like search for the top 20 Japanese restaurants in Boston stuff like that and from the search results screen a user could click on a restaurant to see details about it this detail screen would have more info about the restaurant along with maybe a few snippets from its most recent reviews we'd have an option for a user to see more reviews and if they click on any of these review snippets we would show them the full
and complete review so pretty standard let's tackle a few questions around how we want to store our data for starters where will we put the reviews I mean when I've used this example in previous videos I've generally assumed we've had this kind of database design we've got the restaurants in one collection and all the reviews are in individual sub collections but is this actually the right design let's look at a couple of alternatives alternative number one let's not make these review separate documents like we can stick all the review data into the main restaurant document
as a map or an array of maps once a user clicks on a restaurant I could give them these little review snippets immediately because I've already got them loaded up and hey as a nice little side effect I've also saved myself a bunch of document reads so this is an alternative but maybe not a very good one one problem with keeping our reviews in a map field like this is that when a user decides to search for the top 20 Japanese restaurants in their city we're not only grabbing all the information about the restaurant but
we're also grabbing every single review for every restaurant on that list and that is a bunch of reviews and frankly a whole lot of data that they will probably never need I'm also gonna run into limits either be one Meg of data limit or the twenty thousand field limit if these restaurants get too many reviews I also can't query these reviews either right like I can't filter for just the ten most recent reviews or anything like that I only get back my giant restaurant document with all the reviews in there and if I want to
sort those reviews or filter them or something I would need to do that on the client so I think keeping reviews in their own separate collection is the right way to go but let's look at our second alternative which is what if rather than keeping these reviews as a sub collection for each restaurant they were just in a completely separate top-level collection hey there Todd from 2018 Todd from 2019 we'll handle this one now this gets interesting your first impression might be oh no don't do that it's gonna be a lot harder to get reviews
for a single restaurant but that's not the case remember queries and cloud firestore are always fast so grabbing all reviews for Todd's tacos from a collection of 3 million reviews takes essentially the same amount of time as just grabbing all the reviews from a single subcollection I could also do things like search for all reviews by an individual author without having to enable a collection group query on the other hand some things are a little harder specifically doing something like grabbing reviews for a restaurant sorted by date or sorted by score or sorted by most
popular would require a composite index whereas I wouldn't need that if these reviews were already in their own sub collection also a number of security rules are probably easier to write when I'm dealing with sub collections of a specific document instead of another top-level collection mostly in cases where you're gonna want to restrict access to a sub collection based on what's in their parent document so like I said in the last video if you really think most of your queries are going to be across all reviews and not by restaurant go with a separate top-level
collection but if you think you're mostly going to be doing searches by sub collection keep them that way and add support for the collection Group queries you know you're gonna want to use and so I think I'm gonna go ahead and keep the structure here okay Todd from 2018 back to you now as long as we're here let's talk one further refinement remember that in my restaurant details page I've got my restaurant info and then these snippets from 10 recent review section at the bottom and so with my current database structure I'm either populating these
review snippets from a review sub collection or my reviews top-level collection and that's fine but that does mean bringing up a single restaurant page is now 11 document reads instead of 1 and yes I will get billed for those and if you consider that a typical user might click on some restaurant details skim the reviews go back and repeat that process several times that can add up to a lot of reads and so if I really wanted to avoid all those extra reads I might look at creating a review snippets field in the original restaurant
document this could contain like the first hundred words of the 10 most recent reviews maybe a headline in the author name basically enough to create a presentable reviews but not so much that I'm downloading a ton of unnecessary data for each restaurant and again with the help of some cloud functions which I promise I will talk about in a future video I could keep those in sync now this is nice because I'm now only reading in one document instead of eleven and it simplifies the loading of this page because I only need that one document
which most of the time will already be in memory plus if I ever do need to show more reviews or the full text of one of those reviews then I can read those in from the individual review documents but is this optimization worth the extra code needed to keep these values in sync along with the extra data our user is loading in every time they bring in a restaurant honestly I'm not sure like viewing restaurant details is a user powered action which means it's not going to happen like several times a second right it'll more
often happen like a few times over the course of a several minute session so this could be a case where you end up doing a bunch of work to save like a million reads a day or 60 cents which may or may not be worth it so I think this is one of those situations where you're gonna have to measure what's actually happening in your app and decide accordingly I know that's kind of wishy-washy recommendation right but that's software development for you okay next example how would we store flags for restaurants and I'm talking about
little binary values for like takes reservations is romantic and so on put those away two months ago I would have said the best way to store these would have been either to make these as individual fields inside the restaurant document or group them into a map field and to be honest these are still perfectly reasonable solutions but now that we've added the array contains field I could just as easily put these into it in attributes array then it would be pretty easy to search for all restaurants that take reservations but keep in mind that right
now you can't run to array contains queries on the same array so if I really do want to look for restaurants that are both romantic and kid-friendly which is kind of an oxymoron I know I should keep using separate fields should read the reviews first okay now here's a fairly common case you're gonna come across what about storing a list of users who can access a document now this is a very common piece of data you're gonna want to keep track of particularly in collaborative apps where users can invite like their friends to view or
edit their data and you're going to need to keep track of who can edit what for example let's say our restaurant has a list of editors and these are the user IDs of people who are allowed to edit the restaurant document now I know I haven't really talked about security rules yet that'll be in the next video but one thing you should know about security rules is that they have the ability to grab a specific document and read its content so I could for instance put everybody who's allowed to edit a particular document into an
array and then my security rules could say something like hey only let users edit this document if their user ID appears in this array but what could work better would be to use a map here where our user ID is the key and their value is their role something like editor owner community manager etc and so we could write a security rule that says a user can edit this document if document dot rolls dot user ID equals editor or something like that now this is great but it does have one small issue and that when
you retrieve this document all the contents of this document are transferred along with it remember there's no such thing as a partial document query on the client so you're kind of leaking the list of users and their roles for this restaurant now this may be okay these user IDs are pretty opaque you can't really reverse-engineer them to figure out who the underlying user really is and they are unique per app but still the phrase this may be okay isn't super reassuring when we're talking about security so this information might be better stored outside of this
document in one of two ways option one have a distinct editor subcollection where the document ID might be the user ID of the user and maybe we store this person's role and some other little information about them inside each document or option number two just have a sub collection called private data that contains only one document and this is where you can keep your who has access to what map that we talked about earlier along with other information that you might not want to share with the general public maybe data for your internal sales team
or data that cloud functions will need to performance duties now both of these examples work fine but definitely think about this kind of situation for your app because you will probably want to create access control lists like this and you we'll probably have data associated with the document that maybe you don't want everybody to see okay last example but maybe the most important one what if my user wanted to store a list of their favorite restaurants this is the kind of many-to-many relationship that often is problematic in know sequel databases so first let's assume that
our database has some kind of users collection somewhere well one option is we can just store a list of restaurants as an array in a favorites field for each of these user documents thanks to our new array Union and removal methods it should be pretty easy to maintain this list as our user adds or removes restaurants from their favorites if I load this array in a memory when our application first starts up my client could very easily tag a restaurant as a favorite when we see it in the app the problem though is that it's
hard for us to do a hey here's all your favorite restaurants kind of page using an array like this I'd basically have to do a separate query for every single restaurant ID that I get back from this array in order to populate this page or maybe slightly better get a callable cloud function to do this work for me and I'll talk about that in a later video now this isn't a great experience but it's not terrible either and if I think this feature isn't going to be used very often then this would be a perfectly
fine solution don't let this scare you away on the other hand if this is going to be a frequently used feature there may be ways of making this a little easier and more performant by using some denormalized data for example instead of just storing a list of restaurant ids I can keep like a big ol map of maps that would contain enough data to populate a simple my favorite restaurant screen like maybe I have the restaurant name cuisine type and address stored in this favorites field that might be enough to populate me my favourite screen
and if the user ever wanted more information about a restaurant well then I can query the full restaurant document and populate a restaurant detail screen just like normal but the trick with denormalized data is that we need to make sure that if Todd's tofu hut ever changes their cuisine from Japanese to burgers every copy of that denormalized data has to change as well which means we need to be able to query every user who has this restaurant listed among their favorites so we can make that change as it turns out though we can do that
I can basically create a query that says something like select all users where favorites dot restaurant four two one five is greater than the empty string that would give me a list of all user documents where this restaurant is listed as a favorite in the map field somewhere and it'd be fairly easy to have a cloud function update all those now the disadvantage is that this is a big chunk of extra data that I'm loading per user and we are eating away at my one Meg slash 20,000 fields limit here so I'm gonna need to
limit the number of restaurants my user lists as a favorite although honestly that kind of makes sense if you list 500 restaurants as your favorite hasn't the word favorite lost all meaning who this got kind of philosophical now another option might be to keep my users favorite list as an array of IDs and then keep the restaurant snippets inside the subcollection I could then load a list of the users favorite restaurants in memory without loading all the extra restaurant details along with them but they're also easy to load up if I ever need to show
this favorite screen by querying the subcollection and I can still find a list of users who have favored at a particular restaurant by running in array contains query across my users collection now once I have that it's fairly easy to get at the individual snippets that I need to change although you'll notice I can't do it all in one single query now I basically have to fetch these documents one at a time also just a heads up if you have an array that you're going to use with an array contains query those array elements will
still count against your twenty thousand fields limit so I'm still going to need to limit my user's favorite restaurants to a reasonable number but you know what option might work best here a completely separate top-level collection imagine that I have a favorite restaurants collection every document in there would contain like a user ID a restaurant ID and enough of a snippet about the restaurant to populate a my favorite restaurants page now grabbing all the restaurants favorited by a specific user is a very simple query so creating that my favorites page is very straightforward and it's
just as easy to grab all the instances of a particular restaurant if I ever need to change your update this denormalized data so you know what I'm gonna say this is my favorite option at least for this particular setup whoo all right well that was a lot of examples to go through but I'm hoping by now you're getting a better sense of when to use documents when to use maps when to use sub collections when to use arrays and when to put things in a separate top-level collection now there's always more to explore here and
as you've noticed there's rarely one simple answer to anything there will always be trade-offs no matter what you choose so hey if you have a setup you like better than any of these situations go ahead and share them in the comments below and I will see you on a future episode of get to know cloud fire store planning that's a wrap hi y'all hungry let's go to Todd's tofu hut and here they serve burgers now no no meat burgers I don't know why then change the name ask them no it's a different talk come on
let's just go [Music]
