Document ID strategies in Firebase - Time & Space Complexity
When working with Firebase, how you choose document IDs affects how many operations happen as your data grows.
We want to understand how the number of operations changes when adding many documents with different ID strategies.
Analyze the time complexity of adding documents with auto-generated IDs versus custom IDs.
// Adding documents with auto-generated IDs
for (let i = 0; i < n; i++) {
firestore.collection('items').add({ value: i });
}
// Adding documents with custom IDs
for (let i = 0; i < n; i++) {
firestore.collection('items').doc('item_' + i).set({ value: i });
}
This code adds n documents either letting Firebase create IDs or using custom IDs.
Look at what repeats as n grows:
- Primary operation: Writing a document to Firestore.
- How many times: Exactly n times, once per document.
The main difference is how IDs are assigned, but each write is still one operation.
As you add more documents, the number of write operations grows directly with n.
| Input Size (n) | Approx. API Calls/Operations |
|---|---|
| 10 | 10 writes |
| 100 | 100 writes |
| 1000 | 1000 writes |
Each new document means one more write, so the total grows steadily as you add more.
Time Complexity: O(n)
This means the total number of operations grows in direct proportion to the number of documents added.
[X] Wrong: "Using custom IDs will reduce the number of write operations compared to auto-generated IDs."
[OK] Correct: Both methods write one document per operation; the ID choice does not reduce the number of writes.
Understanding how document ID strategies affect operation counts helps you design scalable Firebase apps and shows you think about cost and performance.
What if you batch multiple document writes together? How would that change the time complexity?
Practice
Solution
Step 1: Understand what a document ID represents
A document ID is a unique identifier for each record in a Firebase collection, ensuring each document can be accessed individually.Step 2: Differentiate from other database concepts
Document IDs are not used for storing passwords, defining database location, or controlling access permissions.Final Answer:
To uniquely identify each record in a collection -> Option AQuick Check:
Document ID = Unique record identifier [OK]
- Confusing document ID with security rules
- Thinking document ID stores data
- Mixing document ID with database path
Solution
Step 1: Identify Firebase methods for adding documents
Theadd()method adds a document with an auto-generated ID to a collection.Step 2: Understand difference from
doc()andset()doc()with no argument creates a reference but does not add data;set()requires a document reference.Final Answer:
UsecollectionRef.add(data)-> Option CQuick Check:
Auto ID creation = add() method [OK]
- Using doc() without set() does not create document
- Assuming set() auto-generates ID
- Passing custom ID when auto ID is needed
const docRef = collectionRef.doc('user123');
docRef.set({name: 'Alice'});Solution
Step 1: Analyze the doc() method argument
Thedoc('user123')call creates a document reference with ID 'user123'.Step 2: Understand set() usage
Theset()method writes data to the document with the specified ID.Final Answer:
'user123' -> Option AQuick Check:
doc('user123') sets document ID = 'user123' [OK]
- Thinking set() changes the ID
- Assuming ID is auto-generated here
- Confusing document data with ID
const docRef = collectionRef.doc();
Solution
Step 1: Understand doc() without arguments
Callingdoc()without arguments creates a reference with a random ID but does not create the document automatically.Step 2: Confirm the issue
The code only creates a DocumentReference; to create the document,set(data)oradd(data)is needed.Final Answer:
doc() without arguments does not create a document automatically -> Option BQuick Check:
doc() alone ≠ document creation [OK]
- Assuming doc() creates document immediately
- Thinking set() is invalid here
- Expecting doc() to require argument always
Solution
Step 1: Understand the goal
The goal is to have document IDs that match usernames for easy direct lookup.Step 2: Evaluate strategies
Usingdoc(username)sets the document ID to the username, enabling direct access by username.Step 3: Compare with other options
Auto-generated IDs or random UUIDs require extra queries to find username; no IDs or relying on order is unreliable.Final Answer:
Use usernames as document IDs by callingdoc(username)-> Option DQuick Check:
Username as ID = direct lookup [OK]
- Relying on auto IDs for username lookup
- Ignoring need for unique IDs
- Assuming collection order is stable
Ready to prove it?
Pass the test and this pattern moves unknown
