大家有什么建议吗？
MongoDB 没有事务原子性，好好考虑哦 我觉得 Postgresql 比较完美，既是 关系型数据库，又支持 json 和 Hstore 字段，事务 和 文档 特性两全了。
谢谢，我比较纠结的是 mysql 设计类似本站的“通知”，“提醒”没有 mongodb 好实现。 比如：
notification = {
[
event: '在主题中提到了你',
topic: {
_id: 1,
title: 'topic title',
xxx: xxx
},
event: '在评论中提到了你',
comment: {
_id: 1,
body: 'comment body',
xxx: xxx
},
event: '你关注的话题有了新的回复',
comment: {
_id: 1,
body: 'comment body',
xxx: xxx,
topic: {
_id: 1,
title: 'topic title',
xxx: xxx
}
},
]
}
这样在 notification 中可以混合多种类型，mysql 我还没有好的思路实现。
#1 楼 @huacnlee #2 楼 @hz_qiuyuanxin #3 楼 @winnie #4 楼 @Rei #5 楼 @Victor #6 楼 @Numbcoder #7 楼 @chairy11 #8 楼 @miclle
MongoDB 等文档型数据库，优点在于方便横向扩展，不过 Ruby 应用的场景来看，性能从来不是出在数据库上，关系型数据库足够。
关系型数据库中，除了 Oracle 和 DB2 有商业支持，功能比较完善，售后支持比较好，适合金融行业技术人员比较懒的解决方案。 而 SQL Server 局限于微软平台，和 自家的 Windows Server && .net 是完美的组合。
那么流行关系型数据库中就剩下 MySQL 和 Postgresql 给我们选择。
- MySQL 是商业公司 Oracle 所有，前途未知，MySQL 创业人都离职写了新数据库。
- Postgresql 是开源社区所有，跟 Ruby，Rails 的优点很像
- 两者优势不一样，性能上 MySQL 快，功能上 Postgresql 强大。
再说一句：性能从来不是出在数据库上。 我选择 Postgresql
@twm https://github.com/tombenner/nested-hstore 可以满足您的需求。
另外，json 类型也可以实现，不过性能差很多。
好消息，2014 年将发布 Postgresql 9.4 版本，其中 Hstore 类型的性能将超过现在的 MongoDB 参考：http://obartunov.livejournal.com/175235.html http://www.sai.msu.su/~megera/postgres/talks/hstore-dublin-2013.pdf
自己做的小应用推荐 mongodb, 这样连 memcache 都省了. 别再纠结了，我就是从 mysql + memcache 全盘用 mongodb 重写的。
昨天看 ruby-china 源码，试着扩展，用脚手架新建一个 resource 后找半天找不到 migrate， 然后明了 mongoid 不需要了 migrate 了；然后找不到 id，再发现有个@huacnlee 写的模块需要 include。。
postgresql 优点：
- 多种数据结构：list, hstore, json, GIS
- 多种存储过程：python, javascript, ruby(instable)
http://sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
看完这个你就可以确定到底要用哪个，Mongodb 和 Sinatra 一样，用法如果错误的话，绝对会处处碰壁的。
我是推荐 Postgresql。在 MySQL 被收购后，现在 Rails 社区已经全面倒向了 Postgresql，Rails 4 针对 Postgresql 有许多特性上的更新。如果没有特别对 MySQL 有历史上的依赖，新项目尝试使用 Postgresql 绝对是不错的选择。
我也建议 PostgreSQL 的说。 MySQL 给收购后，其作者另开了一个叫 MariaDB 的东西，和 MySQL 很像，具体有什么不同可以看看他们的对比列表，像前段时间很多 Linux 的发行版都放弃 MySQL，用 MariaDB 替代，这就说明两者之间兼容性是很好的。
建议在没有确定前，首选关系型数据库，绝大部分场景下它是最优选择。 当你确定业务模型确实需要 NoSQL 的特有功能来支撑时，再迁移也不迟，那时候你的规模也足够大，有足够的资金和人力来做改动。
你的那个用多态不就可以实现了么？这么说下来，你那个不是选数据库的问题，而是看你怎么去设计这个数据结构了。
你还可以设计成
notification = [
{
event: '在主题中提到了你',
event_type: "topic",
_id: 1,
title: 'topic title',
xxx: xx
},
{
event: '在评论中提到了你',
event_type: "comment",
_id: 1,
title: 'comment',
xxx: xx
},
]
}
MySQL 是有模式的，MongoDB 是无模式的 document 存储。通常选择数据库，不是由数据结构决定的，而是由你的项目需求来决定的。例如说：你的项目对事务性的要求很高，那你肯定得选 MySQL；如果只是一般的小项目，那其实选什么都可以。等等之类的。
用 pg 两者兼得。
新项目没必要用 mysql 了。
有很多关联的 model 就别用 mongodb 了，文档数据库的关键是 取 什么就存什么，存的时候就把东西内嵌好，所以才不需要搞 model 级别的缓存。mongodb 的原子操作必须保证修改都在同一个文档内，以前还见过在 mongodb 上重新自己实现跨表事务的做法，囧死了。
#36 楼 @luikore 这个一点都不囧，这个叫高大上的 EAV Pattern，没有资深架构师的水平根本玩不转
http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model
MongoDB 和 pg 解决的不是同一个问题。
在 pg 里，一条记录无论如何都是需要有一个 master 的，不能连到 master 的节点是无法修改这条记录的。pg 只能保证能连到 master 的节点都能修改这条记录。
MongoDB，解决的是不同的问题。假设你有跨地理分布的多个数据中心，你想让尽可能多的来自不同数据中心的节点能修改某条记录。但是，假如你不能连到多数节点，你就不能修改任何一条记录。
