应用场景

用户发布一条动态，动态中可以包含由“##”包裹的话题内容。

一条动态可以包含多个话题，一个话题可以关联多个动态。

数据结构

话题表

• 话题id
• 话题内容
• 创建话题的用户id

动态话题关联表

• 话题id
• 动态id

DBA看到创建数据表的邮件后发问，为什么用MySQL，而不用MongoDB？

他的理由

• MongoDB在文档数达到上亿时仍能保持良好性能，MySQL没有这么强大

我为什么采用MySQL？

• 两张表的schema是比较固定的
• 两张表通过话题id构成关联关系，MySQL支持关联查询，MongoDB不支持
• MySQL按照表的schema对写操作进行约束，MongoDB相反，因为MongoDB的特点就是schemaless
• MySQL支持事务，在发生异常时可以对数据进行回滚，MongoDB暂时还不支持事务

关于数据量的问题

在我的另一篇文章数据库设计的重要性与原则，根据其中的适度超前原则，从目前的每日动态发布量来看，这两张表的数据量在5年内不会达到上亿。

如果达到上亿的数据量，是否真的需要切换到MongoDB？我看没这个必要。即使是MongoDB，数据量达到一定的量之后，读写性能也会急剧下降。

我们有更好的方案来解决读写性能下降的问题，但这是另外一个话题了，本文不做探讨。

DBA这种负责任和敢于发问的态度值得提倡。
我的理由充分吗？