Firestore collection/document diagram
Collections, documents, fields, subcollections and references.
What it explains and when it is useful
Cloud Firestore is a document database. Data is stored in documents (sets of fields), grouped into collections. A document can hold subcollections, and fields can reference other documents. This diagram shows that structure with real field names, types and ID choices.
When to use it: Solutions that use Cloud Firestore (often with Firebase Authentication in web or mobile apps).
Worked example
Illustrative: PracticePal is a fictional project used throughout this guide.
Alternative scenario. The main PracticePal uses SQLite. This shows how its data could be organised if it used Cloud Firestore instead.
Scroll sideways to see the whole diagram.
Notation and legend
| Symbol or part | Meaning |
|---|---|
| Tab shape | Collection (or subcollection) |
| Folded-corner box | Document, with its ID at the top |
| field: value type | A field, its example value and type |
| Dashed arrow | A reference field pointing to another document |
| Path | Where a document lives: collection/doc/subcollection/doc |
Design decisions it communicates
A diagram earns marks when you explain the decisions it shows. In PracticePal's documentation these would each be one sentence:
- Bookings are a subcollection of each room, because the main query is “this room's bookings this week”.
- Waiting-list documents use a chosen ID (room + slot), so the app can read one directly without a query.
- Student details are referenced, not copied, so a name change happens in one place.
- Firestore has no joins or UNIQUE constraints: the clash check must run in a transaction.
Common mistakes
- Drawing an ERD with tables for a Firestore project.
- Leaving out document IDs or how they are chosen.
- Confusing Firestore with Realtime Database (different data models).
- No field types.
Checklist for your own version
Ticks are saved in this browser only, so you can use the list while you draft.