菜鸟问一个mongodb的结构问题

[refresh]

假如我要做一个todo的应用，并且有离线版本，离线用sqlite存储，客户端与服务器端同步。
我是把一个用户的所有todo都放到一个document好呢，还是像传统的关系型数据那样一条一条记录好呢？

第一种：
{id: ObjectId, todos: [title: String, date: Date]}
第二种：
{id: ObjectId, title: String, date: Date}

再复杂一点，TODO再加上记帐的功能，就样就会有统计的需要，例如本周/本月/本年的收支结余之类的。

请问哪种数据库的设计比较好？另外要考虑客户端的sqlite同步，如果服务器端是一个用户一个document，客户端的数据库不一样，同步的时候会比较麻烦，要写的代码会比较多。

虚心求解答，先谢谢各位

[chemzqm]

"如果服务器端是一个用户一个document，客户端的数据库不一样，同步的时候会比较麻烦，要写的代码会比较多"，这话理解不能...

[gaocheng]

代码写的多总比弄个没有扩展性可言的数据库设计好的多

[heroicYang]

todos是无限增长的，所以建议不要使用内嵌文档。

[refresh]

@heroicYang todos是无限增长不错，但一个人的todo总是有限，平均一天10个todo就很了不起了，这样十年才多少。

@gaocheng 扩展性我觉得倒不成问题，主要是对性能会有影响吗，再者就是考虑客户端和服务器端用同一套代码，嗯，用node.js的方案

@chemzqm 我希望服务器与客户端的代码是基本一致的，或者是80%是一致的，但如果数据结构不一致，可能这个目标就达不到了，或者要经过一些周折

[tangzx]

“按查询业务的需求来决定你的数据结构”，这就是mongo。

[tangzx]

如果查询业务仅“列出我的todo"，就按第一种，如果需要大量数据分页，筛选，查看我同事的todo，之类的话就选第二种

[tangzx]

todo无线增长不影响内嵌文档的效率，可以用$push操作符

[leafduo]

最好是要分开，单独的 collection