I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

Re:I/O Is Faster Than CPU – Let’s Partition Resources and El... by crazygringo on Friday May 03, 2019 @03:41PM (#19821588)

> Nowadays, even someone who cares 100% about performance and 0% about data integrity (And is somehow still using a relational database, yeah. So what? It's MY hypothetical.) still has good reason to default to something like 3NF

That's just... wrong.

Best practices with database design are to start with a totally normalized schema because it reduces scope for errors/inconsistencies.

And then to intentionally denormalize where required to increase performance, in order to reduce lookups from joins or computing aggregate functions -- at the cost of having to manually ensure duplicated data remains consistent. Query optimizers can only do so much.

(If it weren't to increase performance, I can't really think of any reason why you ever would denormalize on a single database server, unless you have some extremely complicated calculations that SQL isn't capable of expressing?)

[ Parent | on HN ]

Re:I/O Is Faster Than CPU – Let’s Partition Resources and El... by bunderbunder on Friday May 03, 2019 @04:11PM (#19821831)

> And then to intentionally denormalize where required to increase performance

Hopefully under profiler guidance, like for any other optimization. For my part, the frequency that I find that trying a denormalization helps performance has been on a downward trend for a while now. Mostly down to just straight-up duplicating data at this point. Databases really are getting very good at what they do.

[ Parent | on HN ]