กลยุทธ์การทำข้อมูลไม่เป็นบรรทัดฐานและการทำซ้ำข้อมูล

Realtime Database has no joins. Instead of normalizing data like a relational schema, you shape data around how you read it. This often means storing the same value in more than one place.

This deliberate redundancy is called denormalization.

In a normalized model, showing a post with its author name would require reading the post, then reading the user node separately for every post. That is many round-trips and slow lists.

Instead, copy the small bits you display alongside the post. Now one read renders the whole feed item.

Duplicate only the fields you actually display in lists, not entire records.

• Names, avatars, titles: good candidates
• Large or sensitive fields: keep them in one place
• Rarely-changing data: safest to copy

The cost of duplication is keeping copies in sync. If Alice renames herself, every copy of authorName must update. You trade write complexity for read speed.

Update all copies atomically with a single multi-path write so no copy is left stale.

Another denormalization pattern is the index node: a lookup mapping that lets you find related items without scanning. Here we map a user to their post IDs.

Reading a node downloads everything beneath it. Keep your tree shallow so a read does not pull in unrelated children. Split large nested structures into sibling top-level nodes.

Denormalization is not always right. Avoid it when:

• The duplicated field changes very frequently
• There are many copies to keep consistent
• The data is large or rarely read together

In those cases, store once and read separately.

Use Security Rules .validate to keep duplicated fields trustworthy, for example ensuring an authorName copy is always a non-empty string.

The golden rule: structure data around your most common reads. Write the queries your app needs first, then shape (and duplicate) data so each one is a single, shallow read.

Test your understanding of denormalization.

You can now model NoSQL data for speed.

• Denormalize by duplicating displayed fields
• Keep copies in sync with multi-path updates
• Use index nodes for relationships
• Keep the tree shallow to avoid over-fetching
• Structure data around your common queries