We’ve all done things in relational databases for many many years and we’ve become really good at doing that.When we come across the document databases we have to retrain our brain. We have to think slightly differently when we do this otherwise we may run into some challenges.
If you think in the world of relational data you always had a model first. You thought about your tables and thought about what went in and you built your schema.So just because we’re in a document database that doesn’t mean we don’t model .we’re still modeling as just as in a relational database. It’s a little bit different where the relational data engine typically enforcing your schema or in a document database engine typically it’s the developer that’s enforcing that schema.So you build your models it’s usually built from some use case that you’re working on and driven from your code on down to the database.
Set the context how fundamentally different the approaches are. I’m going to find a scenario quickly and then to two extreme scenarios one on either end of the spectrum but it should give a good idea of the difference between the two approaches.
Let’s say I’m building an application that deals with Motor Vehicles. I want to display a motor vehicle on the screen.I may use some kind of ORM or some kind of mapping tool or some kind of middleware that takes my app and changes the format and then store it in the database separately.In a relational database, you may actually take the motor vehicle and break it up into component parts and store each one of those component parts in their own kind of table.I may store all wheels together and all engine blocks together and you get the idea very extreme.You probably wouldn’t model a database quite as extreme as the picture but you know you get the idea and then when you want to display the vehicle again on the page you write a bunch of code either in the database or in this middle tier or in your application to take all of these parts reassemble it back to a motor vehicle and then present the motor vehicle on the page.
The other side of the spectrum in a document database is, you have a motor vehicle and you send that over the wire as it is and you persist that whole motor vehicle as a motor vehicle object in the database and when you want to display that motor vehicle on the page you do a query for the motor vehicle you bring it down to the page over the wire and you display it on the page.Those are the two different kinds of extremes.
If we take a look at a more realistic data modelling example a person and a person has contact details a contact detail has a type and we split these up into separate tables, we use foreign keys to kind of you know to break this up and reassemble the object and that ‘s what it would look like in a relational world.
A document world we take a document called the person and we have attributes and on that, we may actually go and embed in and address a contact detail or multiple contact details and this is what the same thing would look like in a JSON document.
Why we need Document Database?
The document database is expressive, efficient, and flexible. Create shallow queries to retrieve data at the document level without needing to retrieve the entire collection or any nested subcollections.
Firestore Document Database
Cloud Firestore is a flexible, scalable database for APP.It keeps your data in sync across client apps through realtime listeners and offers offline support for mobile and web so you can build responsive apps that work regardless of network latency or Internet connectivity. Cloud Firestore also offers seamless integration with other Firebase and Google Cloud Platform products, including Cloud Functions.
How does it work?
Cloud Firestore is a NoSQL database that your apps can access directly via native SDKs.
Following Cloud Firestore’s NoSQL data model, you store data in documents that contain fields mapping to values. These documents are stored in collections, which are containers for your documents that you can use to organize your data and build queries. Documents support many different data types, from simple strings and numbers, to complex, nested objects. You can also create subcollections within documents and build hierarchical data structures that scale as your database grows.
Add, sorting, filtering, and limits to your queries or cursors to paginate your results. To keep data in your apps current, without retrieving your entire database each time an update happens, add realtime listeners. Adding realtime listeners to your app notifies you with a data snapshot whenever the data your client apps are listening to changes, retrieving only the new changes.
Firestore Data Model
Firestore is a document database that means it kind of stores your data in a big tree like structure kind of like the original real-time database but everything is placed into documents and collections.
You can think of a document is something kind of like a map it’s got key-value pairs which is the Firestone folks like to refer to as fields and the values of these things can be any number of things from strings to numbers to binary values to little small maps that are kind of JSON looking objects.
The collection is basically well collections of documents.
There are a few rules around the use of this thing.
Rule 1: Collections can only contain documents nothing else no collections of strings or binary or anything else.
Rule 2: Documents can’t contain other documents but they can point to sub collections so it’s very common to see a collection containing a bunch documents which then point to sub-collections that contain other documents and so on in a user workout app for instance.
I might have a users collection and this collection would contain a document for each user and then each of those documents might point to a workout subcollection that in turn contains a document for each different type of workout that this user is performed and then maybe each one of these has a history sub-collection that keeps track of every time the user performed one of these workouts may be along with like some average heart rate data or some other stuff like that.
Rule 3: The root of your database can only consist of the collection now in a normal production app this is going to feel pretty natural.
If you’re coming from real-time database land this kind of deep nesting might be giving you heart palpitations but don’t worry this kind of data structure is completely normal in the cloud Firestore world where queries are shallow meaning that when you grab data from a document you’ll garb just that document not any of the documents contained in any of the sub-collections below which nice.