3 ms·
This article seems to ignore common denormalization patterns that don't cause problems, e.g. denormalizing immutable data such as row ids. These reduce the numb
by antonvs 3y ago
This article seems to ignore common denormalization patterns that don't cause problems, e.g. denormalizing immutable data such as row ids. These reduce the number of joins needed, and make code simpler and faster, refuting one of the article's claims about code complexity due to denormalization.
The article seems to be saying that the trade-offs of denormalization often aren't being correctly evaluated. Without examples or specific advice, this is not particularly useful information.
- _a_a_a_ 3y ago> denormalizing immutable data such as row ids I'm a bit unsure, can you give an example of what you mean, and indeed, of what you mean by a row ID, thanks
- antonvs 3y agoSorry, I expressed that poorly. I was trying to refer to something more general than a primary key, but primary keys are probably the best example. But the same kind of optimization can be used on any value which is essentially immutable. Consider the following schema: company: (company_id, company_name) user: (user_id, user_name) company_users: (company_id, user_id) transactions: (transaction_id, user_id, company_id, amount, date) The presence of company_id in the transactions table is a denormalization, since the source of truth in that case is actually the `company_users` table. But assuming the ids in the system are immutable, this optimization doesn't suffer from any of the issues raised in the OP article. It makes for simpler code that executes faster. It doesn't "deprive us of the correct answer to the problem."