点赞 数据库设计

现在实现了点赞功能，
主要涉及了两个表，
一个是文章或博客保存点赞的数量，另一个是用户点赞记录；
现在的问题是每次点赞都会进行数据的读写操作（特别是写），并发的话会导致数据库压力太大，请问如何解决？谢谢。
建议增加点赞表, 字段列表:
用户id,
主题id,
点赞时间,
状态. 0-已取消赞 1-有效赞

就像楼上所说的这样，这是经典的数据库设计中处理多对多关系的方式。这样的记录数会特别多，每一个用户赞过的每一条微博都会有一条记录，如果真的像新博微博业务量那么大的话，就要考虑做分库分表（即sharding）了。这种方案就复杂多了，我也没做过。你再根据你的业务情况考虑一下吧。

数据库设计 类似微博中的内容和评论、点赞等需要分离出两个表吗？

应用需求类似微博这样，用户发布一条微博，数据分为两类
1、内容：内容、日期、与其用户发布的地理位置等等。这些数据基本没啥变动。应该叫冷数据
2、点赞、评论数等。这些数据频繁变动，应该叫热数据。

我现在的疑问就是：针对这个场景，如何设计数据库？
需要分成两个表吗？一个表读比较多，一个表写比较多，这样分出来是不是有好处？

冷热数据物理存储分开存储的思路是对的，冷热数据读写特性不同（冷数据的读写比例高于热数据），分开储存之后可以采用不同的cache策略，冷数据因为更新少可以直接同步一份至redis这类NOSQL服务，业务层直接从redis读取，减少对mysqldb的压力；热数据因更新较频繁，可以根据用户id（或者说uin）hash到多台写服务，并先写至写服务器的本地缓存中，再异步定时批量更新至mysql，减少对mysql的写压力。