3 ms·

Read the whole article and I still don’t know what denormalization is

lcnPylGDnU4H9OF 3y ago
The target audience is those who do. It's a complex enough topic that it's reasonable the author chose not to explain it (an early question of "where do I begin?" doesn't have an easy answer). "Denormalization" is saving data in the "wrong" place in a database so you don't have to do a join to a different table. It's "normalized" if the textual data[0] (e.g. a name) is all in the "correct" place (e.g. the user profile) and not in the "wrong" place (e.g. the user's comment). In a normalized database, the comment displaying the username would have a reference to the user record, which has a reference to the user profile record (assuming those are separate; they're often not). https://en.wikipedia.org/wiki/Third_normal_form https://en.wikipedia.org/wiki/Third_normal_form [0] "Non-primary-key data" but I don't know how helpful the extra technical jargon is.
Jtsummers 3y ago
The reverse of normalization. You normalize by moving redundant or non-related columns into other tables. For instance, instead of having a table with (cart id, product id, price) you'd normalize by creating (cart id, product id) and (product id, price) tables. The (product id, price) table is a single source of truth, and, now, no matter what cart something is in the price is known to be correct (or as correct as the product price table). And updating a price means one edit, not many edits. Denormalization takes that normalized form and reverses it. Often for performance reasons. If updating prices is a rare occurrence, for this example, then getting the price total for a cart is slowed by forcing an extra join. Denormalizing brings the price back into the (cart id, product id, price) table and now the total price of a cart is a single query, no joins required.
KMag 3y ago
A normalized data model has no redundancies. In the best cases, denormalization is caching sub-queries within the database by storing the same (or equivalent after transformation) data in multiple places. However, that requires more complex transactions to keep everything consistent every time you update data. If done carefully and correctly, you can sometimes get better read performance from denormalized data. As others have pointed out, materialized views give you the same advantages as denormalization, except the database takes care of keeping everything consistent. In the worst cases, denormalization is an excuse to not think too hard about organizing your data, hand-waving that the database will perform better with redundancies.
deleted 3y ago
[deleted]

The target audience is those who do. It's a complex enough topic that it's reasonable the author chose not to explain it (an early question of "where do I begin?" doesn't have an easy answer). "Denormalization" is saving data in the "wrong" place in a database so you don't have to do a join to a different table. It's "normalized" if the textual data[0] (e.g. a name) is all in the "correct" place (e.g. the user profile) and not in the "wrong" place (e.g. the user's comment). In a normalized database, the comment displaying the username would have a reference to the user record, which has a reference to the user profile record (assuming those are separate; they're often not). https://en.wikipedia.org/wiki/Third_normal_form https://en.wikipedia.org/wiki/Third_normal_form [0] "Non-primary-key data" but I don't know how helpful the extra technical jargon is.

Jtsummers 3y ago

The reverse of normalization. You normalize by moving redundant or non-related columns into other tables. For instance, instead of having a table with (cart id, product id, price) you'd normalize by creating (cart id, product id) and (product id, price) tables. The (product id, price) table is a single source of truth, and, now, no matter what cart something is in the price is known to be correct (or as correct as the product price table). And updating a price means one edit, not many edits. Denormalization takes that normalized form and reverses it. Often for performance reasons. If updating prices is a rare occurrence, for this example, then getting the price total for a cart is slowed by forcing an extra join. Denormalizing brings the price back into the (cart id, product id, price) table and now the total price of a cart is a single query, no joins required.

KMag 3y ago

A normalized data model has no redundancies. In the best cases, denormalization is caching sub-queries within the database by storing the same (or equivalent after transformation) data in multiple places. However, that requires more complex transactions to keep everything consistent every time you update data. If done carefully and correctly, you can sometimes get better read performance from denormalized data. As others have pointed out, materialized views give you the same advantages as denormalization, except the database takes care of keeping everything consistent. In the worst cases, denormalization is an excuse to not think too hard about organizing your data, hand-waving that the database will perform better with redundancies.

deleted 3y ago

[deleted]