Data Organization in Firestore

Cloud Firestore is a NoSQL, document-oriented database. There are no tables or rows, and data is stored in the documents, which are organized into collections. Each document contains a set of key-value pairs to identify a document. These key-value pairs are optimized for storing a large collection of small documents.

All the documents must be stored in collections. Documents can contain sub-collections and nested objects, which can include primitive fields like string or complex objects like lists.

A document is a light weighted record that contains a field, which maps to values. A name identifies each document, and we can treat documents as lightweight JSON records.

Complex, nested objects in a document are known as maps.

Collections

Documents reside in collections, which are very simple containers for documents. Collections are schema-less. We have freedom over the fields which we put in each document and data types that we store in those fields. Documents that are in the same collection can contain and store different fields and different types of data in those fields.

• A collection contains documents and nothing else.
• It cannot directly contain raw fields with value.
• It cannot contain other collections.
• The names of the documents within a collection are unique.
• We can provide our keys, such as user IDs.
• We can allow Cloud Firestore to create random IDs for us automatically.
• There is no need to create or delete collections.
• The collection exists, when we create the first document.
• If all the documents in a collection are deleted, the collection will not be longer exists.

Sub-collections

A sub-collection is a collection associated with a specific document. We can create a sub-collection called messages for every room document in our rooms collection.

When we structure our data in Cloud Firestore, we have the following options

• Documents
• Multiple collections
• Sub-collections within documents.

We can nest complex objects like arrays or maps within documents. It is easy to set up and streamline our data structure if we have a simple, fixed list of data. The document grows, with larger or growing lists that can lead to slower document retrieval times. So it is not scalable as another option.

We can create collections within the document when we have data that might expand over time. As our list grows, the size of the parent document doesn't change and also get full query capabilities on sub-collections. There is one drawback or limitation of sub-collections, i.e., we cannot easily delete sub-collections.

Example

Root-level collections

In the root-level collection, we create collections at the root level of our database to organize disparate dataset.

Example

• Each document is uniquely identified by its location within the database:

• We can also create reference to collections

• We can also create references by specifying the path as a string. The path components are separated by a forward slash(/).

Example

Creating a reference to a message in the sub-collection