Data denormalization is broken
I don&#x27;t think, as the article claims, data denormalization is broken. I think most programmer&#x27;s knowledge of SQL is scrawny --- unexpectedly so for a language that&#x27;s 30 years old and underpins most applications. SQL was obviously meant to be simple, almost declarative, and resembling plain-English sentences. And yet it&#x27;s the first thing that developers abstract away with an Object Relational Mapping, much to their loss.<p>The article&#x27;s example is one-to-one chat with millions of users. It says that counting unread messages is too slow unless you denormalize it.<p>First of all, the Rooms aren&#x27;t a core table. If each Room has just two people, as the article says, then all you need is one table, messages:<p><pre><code>    a  |   b   |        sent         |      body      |        read
  -----+-------+---------------------+----------------+---------------------
   ed  | tom   | 09&#x2F;29&#x2F;2016 14:22:10 | Hi             | 09&#x2F;30&#x2F;2016 02:02:15
   tom | ed    | 09&#x2F;30&#x2F;2016 02:03:15 | What up?       | 09&#x2F;30&#x2F;2016 02:04:03
   sue | sally | 09&#x2F;30&#x2F;2016 08:19:20 | Catch ya later |
</code></pre>
So the count of unread rooms is:<p><pre><code>  select count(1) from (select distinct a from messages where b = :user and read is null) t;
</code></pre>
If the columns are indexed, I would think PostgreSQL could handle such queries in a split second, even with millions of rows.<p>At Facebook&#x27;s scale, where you have hundreds of millions of users, then you will have hundreds of billions or rows, maybe trillions. Okay, so it might start to get slow that this point. But let&#x27;s stop for a second and remember that 99.999% of web applications will never reach Facebook&#x27;s scale.<p>In Facebook&#x27;s case, I read a long time ago that they make a database for each user. If so, the aforementioned table and query would still work --- in fact without the need for the b column.