4 ms·

I think that the linked blog post goes a bit overboard. Atwood himself says repeatedly that you should start with a normalized schema; he just also says that de

by gecko 18y ago

I think that the linked blog post goes a bit overboard. Atwood himself says repeatedly that you should start with a normalized schema; he just also says that denormalizing for performance reasons should not have such a strong stigma attached, given that it's the only way to make big, massive databases work correctly. We can argue over whether Atwood is arguing to optimize a bit too early, but the general idea he's expressing is neither new nor (at least among experienced DBAs) disturbing.

ars 18y ago
Except that the premise is wrong! Denormalizing will not help you speed up the database. It's a false argument. It just won't do that. There are specific table structures combined with specific query type that can be denormalized to speed things up. But a normal table will not speed up in the slightest, in fact most of the time it will slow down! It will slow down because if you need only 1 column out of several, the larger each row is the slower the access will be. Denormalizing is even worse for large sites. By normalizing you can often put some tables on one machine, and others on a different one. For example screen_name and phone number, which jeff combined. Screen_name is used by the chat program, and phone number by the profile page. Run the chat program on a totally different set of machines. All you need to send it is the user_id.
- IsaacSchlueter 18y ago
  I get what you're saying. But I think "screen_name" is used here to indicate the IM links that some sites let users put on their profile. They then create the little ymsgr:sendIM?user_name hyperlinks so that you can IM that person. So, that IS actually something that would go on the profile page, right with the phone number. I'd always heard that normalization should only be done at sane data boundaries. IE, if you have a bunch of fields that always go together, they should be in the same table.
  - ars 18y ago
    The thing with screen_name was just an example of how normalizing could help with speed. It wasn't meant to be definitive. Plus for the profile page you could just get the data from that other server. >I'd always heard that normalization should only be done at sane data boundaries. IE, if you have a bunch of fields that always go together, they should be in the same table. No, not exactly. It's too big of a subject to explain in a post like this, plus there is tons of text on it if you search. But, basically normalization removes duplicated data from the database. It's also used to allow multiple X to exist for a single Y without having columns like X_1, X_2, X_3, etc. And finally it's used to show relationships between things. There are some people will will simply split a table into two tables along logical boundaries (but still, just one row in each table). This is not normalization. It can be done if some data is accessed rarely, or because the database can not handle such a big table, but it's not because of normalization.
omouse 18y ago
"[denormalizing for performance reasons is] the only way to make big, massive databases work correctly" How about a column-oriented database? http://en.wikipedia.org/wiki/Column-oriented_DBMS http://en.wikipedia.org/wiki/Column-oriented_DBMS Would that help much? (I don't know much about databases :S)

by gecko 18y ago

ars 18y ago

Except that the premise is wrong! Denormalizing will not help you speed up the database. It's a false argument. It just won't do that. There are specific table structures combined with specific query type that can be denormalized to speed things up. But a normal table will not speed up in the slightest, in fact most of the time it will slow down! It will slow down because if you need only 1 column out of several, the larger each row is the slower the access will be. Denormalizing is even worse for large sites. By normalizing you can often put some tables on one machine, and others on a different one. For example screen_name and phone number, which jeff combined. Screen_name is used by the chat program, and phone number by the profile page. Run the chat program on a totally different set of machines. All you need to send it is the user_id.

IsaacSchlueter 18y ago
I get what you're saying. But I think "screen_name" is used here to indicate the IM links that some sites let users put on their profile. They then create the little ymsgr:sendIM?user_name hyperlinks so that you can IM that person. So, that IS actually something that would go on the profile page, right with the phone number. I'd always heard that normalization should only be done at sane data boundaries. IE, if you have a bunch of fields that always go together, they should be in the same table.
- ars 18y ago
  The thing with screen_name was just an example of how normalizing could help with speed. It wasn't meant to be definitive. Plus for the profile page you could just get the data from that other server. >I'd always heard that normalization should only be done at sane data boundaries. IE, if you have a bunch of fields that always go together, they should be in the same table. No, not exactly. It's too big of a subject to explain in a post like this, plus there is tons of text on it if you search. But, basically normalization removes duplicated data from the database. It's also used to allow multiple X to exist for a single Y without having columns like X_1, X_2, X_3, etc. And finally it's used to show relationships between things. There are some people will will simply split a table into two tables along logical boundaries (but still, just one row in each table). This is not normalization. It can be done if some data is accessed rarely, or because the database can not handle such a big table, but it's not because of normalization.

omouse 18y ago

"[denormalizing for performance reasons is] the only way to make big, massive databases work correctly" How about a column-oriented database? http://en.wikipedia.org/wiki/Column-oriented_DBMS http://en.wikipedia.org/wiki/Column-oriented_DBMS Would that help much? (I don't know much about databases :S)