Yea, I think this article is just flaunted stupidity. The author assumes that all times where any user information is needed, that all the information about th

Yea, I think this article is just flaunted stupidity. The author assumes that all times where any user information is needed, that all the information about that user will be needed. That is silly. Secondly, they completely ignores the billion and one problems he will now have. For example, how do you ensure that the same AIM username is not used on multiple accounts? With the normalized schema, this is trivially done via a unique constraint on the user_id, screen_name, im_service triplet (probably the 3 make up the composite primary key of the table anyway, so viola, consistent data is ensured). With the de-normalized schema, you are hopelessly fucked. All data consistency would be forced into some kind of ugly trigger. Finally, joins are really-really-really fast for things like this. Frankly, the real thing that bites you is inconsistent data that violates basic assumptions your application makes, leading to unintended behavior of your application, most often exceptions that are not handled reasonably. In this case, for example, you might have a way to find your friend via AIM login name, but your app blows up when 2 seperate users are returned by the query due to there being 2 results (or you or your orm only get the first result, making finding the actual friend impossible). And on and on. It is better to have slower fully reliable data than faster bullshit.