mongo设计原则问题

            还行吧！H不错。
        

            其实这就是典型的以空间换时间，或者以时间换空间的数据存储方式的选择。
如果数据据量不大的话，建议还是按照Z的方式，传统的关系型数据结构。
当然对于大量的数据，这也是mongodb的优势，可以牺牲空间来换取查询效率的提高等方面。
        

            说来说去，还是没个定论。
        

            数据库方面不太懂，说错勿怪
这两人争论的是不是就是数据库不在一个轨道啊。
对于mongodb而言不存在关系这个说法，Z的想法依然还是固有的关系型数据库上。
2楼说的蛮对的。看数据量，上千万以上的数据量使用mongodb，也就是H的想法。
        

            用mongodb一般是为了速度、高并发、集群，用nosql时不能老想着关系型数据库和范式，需要看实际应用的场景，如果Category表当做字典用就行了，在Food中做适当的冗余在检索时能提高不少的性能，H的做法在效率上更好一些。
        

            这个问题，其实很有意思，事实胜于雄辩，让H和Z都把东西做好。
然后，分别测试1k，10k，100k,1kk,100kk的数据量就行了呀。
远比这么争执，来的快速。
而且，可以看出，使用哪一种方法开发的时候效率更高。
MongoDB是大数据存贮更佳，所以，我个人比较倾向于H的思路。
按照传统的R数据库的思维来看。
为了能够更快的得到查询结果，一般都会使用，复制表和视图。
通过trigger当表更新的时候，同步刷新视图中的数据。
视图的数据，是专门为某一个或者一类查询，进行优化生成的。一般是不考虑表结构的，只考虑查询的速度。
关于
问题：H说有这种需求：客户端根据Food信息获取到categoryName（这种需求目前短期来讲未规划此功能，以后也不一定有）。
我想说，大家其实，可以想象一下，婚宴的菜单，1888,3888,9888的价位。
其中的菜肯定会有不一样的地方。但是，客户会说，我希望5888的菜单中也有，9888菜单中的，某几个菜。
不是说，客户没有需求，而是目前这种需求，是不是需要实现。
        

            第一，该应用场景中数据量不会很大，不建议选用MongoDB。
第二，考虑两种设计合理性时，需要充分考虑数据读和写的要求。比如：
1.要保证写入数据原子性的话，使用嵌套文档形式更合适。
2.查询的数据经常需要列出Category下所有food的话，那么一种可以考虑的方案是：
{
  Category：C1
  food：[{food1},{food2}....]
}