Hacker News Reader

Comment by mabbo | Hacker News Reader

In 2004, I started community college program and had a professor teaching intro to databases. He was retired from industry and had lived through the rise of RDBMS's and made his money in that. Teaching was just his hobby. He liked to have fun with the class (120+ of us) by having us do call-response things as a group.

Prof: "Why do we normalize?"

Class, in unison: "To make better relations."

Prof: "Why do we denormalize?"

Class, in unison: "Performance."

It took a lot of years of work before the simplicity of the lesson stuck with me. Normalization is good. Performance is good. You trade them off as needed. Reddit wants performance, so they have no strong relations. Your application may not need that, so don't prematurely optimize.

View on HN

"Performance is good" is I think something everyone could agree with just hearing it for the first time. There's no reason to prefer worse performance if you can have better performance for no additional cost. Is the same true for normalization? Why is just the state of being more normalized inherently better?

because a normalized database repeats less things and is much easier to understand than a messy one.

oh, and also, the entire point is that neither is "inherently better"... both have pros and cons

I think my point was "performance" in the sense of faster response time is inherently good. All things being equal, if you have a more performant option you'll choose that. The only time you accept worse performance is in pursuit of some other metric.

On the flip side, "normalization" doesn't have that same inherent good-ness. All things being equal (including performance) there isn't any inherent drive toward more normalization, maybe because a faster performing page will have clear impact to the user while a more normalized data structure would be completely transparent to the user?

sure, from the perspective of the final user it doesn't matter much at all.

with my point about normalization being easier to understand I meant to say that it is easier for a developer learning about the schema.

if I recall ok, I think there's also something about data de-duplication in a normalized database. without this normalization, you could get a lot of repetition, which would actually require to update the same data in multiple places or find some other way to deal with different data about the same entity (some sort of de-synchronization is more likely without normalized schemas).

in any case, I'll grant you that normalization should never be 'the' goal for a database.

Denormalized means it has multiple copies of the same pieces of data. The application is responsible for keeping those copies in sync with each other. This is a messy process that is easy to get wrong now and then. Then your app starts saying things that are absurd. No one cares much if Reddit does that every now and then.

Some levels of normalisation don't allow nulls. This is absurd. Normalisation alone is theoretical concept which should not be blindly pursued in practice, even without performance requirements.

Normalized schemas are less prone to certain kinds of hard-to-solve issues.

Example: When you have the same data in two places, which is authoritative? If they disagree, which one is right?

And querying data reliably is much easier when you've got good relations that can be relied on to be accurate. SQL is almost a masterpiece (though imho it should have been FROM, WHERE, SELECT).

> don't prematurely optimize

Premature optimization is the root of all evil

So is premature pessimization.

Careful with repeating mantras without reflection.

You may end up using them as arguments when they're just catchphrases that require context.

See people who used "goto considered harmful" as an absolute to never use goto (C).

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”

How dare you bring full quotes and context to a discussion :)

Seriously true, though. What's usually missed is the first bit, about "small efficiencies", combined with the last bit, the "critical 3%". He's basically saying don't spend time in the mass of weeds until you know where the problems really are, but conversely take the time to optimise the smaller areas that are performance-critical.

Almost the opposite of the carte-blanche overly-minimal MVPs often thrown together by those of us who forget what the V stands for.

Tuple table performance, though, tends to degrade quickly when querying separate rows for every little attribute.

More _memory_ and row caching in RAM has allowed for a resurgence in denormalized schema.

FB's underlying schema is similarly just a few tables. But the entire dataset is memcached.

> Tuple table performance, though, tends to degrade quickly when querying separate rows for every little attribute.

Interesting. Do you know what causes this steep decline in performance?

A larger sequential read is typically not that much slower regardless on what sort of drive you are using. I'd have expected that the random access pattern of a normalized table would lose out.

Reply on news.ycombinator.com