What is denormalization, and why it might be useful in AppSheet?
When we start working with databases, weโre taught to normalize:
split entities into separate tables, connect them using Ref, and avoid data duplication. All good.
Buuutโฆ in AppSheet, strict normalization can backfire.
Why? Because more tables = more sync time = slower apps โณ.
๐ก Denormalization means:
Copying a piece of data instead of referencing it.
For example:
Instead of using [client_id].[name] through a Ref, you directly store [client_name] as plain text when adding the row.
Yes, itโs duplicateโbut you load one table instead of three. ๐จ
๐งช When do I use it?
-
When the app only reads data.
-
When you want to reduce sync time.
-
When the copied data doesn't change often.
โ ๏ธ When to avoid it?
-
If the data changes frequently.
-
If you need related rows (Related Orders, etc.).
-
If real-time consistency is essential.
โ๏ธ In short:
Denormalizing isn't breaking the rulesโit's knowing when to bend them.
If it makes your app faster and simpler, it's a smart trade-off.
LinkedIn
Twitter
