如果单论数据库表的设计，你都已经给出来了，这是最直观的设计！

• 如果现在的设计能够很好满足你的需求，工作的很好，那就没必要为了所谓的易于扩展、性能等理由去重构。简单直观且能满足当前的需求，就不要盲目的去过度设计，每次显示评论的时候，就老实地关联查询，然后 order by created ，然后取前3条记录；
• 如果无法满足需求(一般大多是性能需求)，那就需要分析性能瓶颈在那里。个人先猜一下：一般瓶颈也就是在数据量很大时候，最新3条评论的获取。针对这个性能热点，简单给一下个人的看法，欢迎拍砖：
  1、最简单的做法，加索引 (article_id, created) ，能够很好增加SQL的查询效率，基本能够解决问题；
  2、此外，可以在article表增加一列，存储最新3条评论的信息，这个信息可以根据 (comment_id, created) 组合，这样既方便插入新评论时的更新，也可根据主键id直接查询最新3条评论，不过这种方式，增加了插入评论时的开销，需要权衡；
  3、再者，可以利用缓存，将最新3条评论放到缓存中，当然最好是能够放到内存缓存中，如果数据量大的话，可以考虑类似memcache的分布式缓存，这样同样可以大大减轻数据库的查询压力；
  4、最后，稍发挥一点，直接上nosql数据库，类似mongodb、redis等nosql数据库能够很容易满足这样的业务场景，只是这样带来了新的学习成本。

上述只是个人的一家之言，对于大多数这样的业务场景，在数据量不是特别大的时候，类似楼主的表结构，外加有效的索引，完全能够handle。