Remember, when you structure your data in Cloud Firestore, you
have a few different options: documents, multiple collections, and
subcollections within documents. Consider the advantages of each option as they
relate to your use case.
Nested data in documents
You can nest complex objects like arrays (maps) within documents.
- Advantages: If you have simple, fixed lists of data that
you want to keep within your documents, this is easy to set up and streamlines
your data structure.
-
Limitations: You can't run queries on nested lists.
Additionally, this isn't as scalable as other options,
especially if your data expands over time. With larger or growing lists, the
document also grows, which can lead to slower document retrieval times.
- What's a possible use case? In a chat app, for example, you
might store a user's 3 most recently visited chat rooms as a nested list in
their profile.
|
- class alovelace
- name :
first : "Ada"
last : "Lovelace"
born : 1815
rooms :
0 : "Software Chat"
1 : "Famous Figures"
2 : "Famous SWEs"
|
Subcollections
You can create collections within documents when you have data that might expand
over time.
- Advantages: As your lists grow, the size of the parent
document doesn't change. You also get full query capabilities on subcollections.
-
Limitations: You can't easily delete subcollections, or
perform compound queries across subcollections.
- What's a possible use case? In the same chat app, for
example, you might create collections of users or messages within chat room
documents.
|
- collections_bookmark science
- class software
name : "software chat"
- collections_bookmark
users
- class
alovelace
first : "Ada"
last : "Lovelace"
- class
sride
first : "Sally"
last : "Ride"`
- class astrophysics
|
Root-level collections
Create collections at the root level of your database to organize disparate data
sets.
- Advantages: Root-level collections offer the most
flexibility and scalability, along with powerful querying within each
collection.
-
Limitations: Getting data that is naturally hierarchical might
become increasingly complex as your database grows.
- What's a possible use case? In the same chat app,
for example, you might create one collection for users and another for rooms and
messages.
|
- collections_bookmark
users
- class alovelace
first : "Ada"
last : "Lovelace"
born : 1815
- class sride
first : "Sally"
last : "Ride"
born : 1951
- collections_bookmark rooms
- class software
- collections_bookmark
messages
- class
message1
from : "alovelace"
content : "..."
- class
message2
from : "sride"
content : "..."
|
Нужна помощь? Обратитесь в