mongo设计原则问题

天地一少鸥 发布于 2013/04/25 11:25
阅读 2K+
收藏 0
MongoDB数据关联问题,请大家给评评理,孰对孰错

    Hi,大家好,最近公司在做的一个项目中用到了mongodb,但是有一个问题想请教大家一下,尤其是mongodb开发人员,因为同事Z不懂mongodb,但是Z无法说服同事H,H也说服不了Z,所以想来mongodb社区来请教各位一下。到底是谁对谁错?
    情景假设:假设每个饭店内都有Category信息,每个Category下面又都有Food信息,Category信息内会保存categoryId,categoryName,categoryIconUrl等信息;Food信息内会保存foodId, categoryId, foodName, foodPrice, foodIconUrl等信息。
    问题:H说有这种需求:客户端根据Food信息获取到categoryName(这种需求目前短期来讲未规划此功能,以后也不一定有)。
    但是在实现方式上Z和H有了分歧,Z觉得正常的且简单的逻辑是根据Food内的categoryId,然后以categoryId为参数向服务器请求此Food所在的Category的信息,服务器会查找此categoryId的Category,这样就得到了categoryName,
    同事H负责服务器和mongodb开发,觉得应该这样:客户端在添加新的Food的时候,跟服务器通信时应该加上categoryId和categoryName参数,这样在服务器端的Food信息中就会保存categoryId和categoryName,这样当客户端发起请求时服务器就会少了一次查询。H的观点:修改categoryName的几率很小,总体上讲改的话不会浪费太多资源;2.如果客户端需要获取categoryIconUrl的时候不是还是需要通过categoryId来获取Category信息?category信息不多,如果需要获取categoryIconUrl的话,那么在服务器端也一并把它放在Food中就好了。Z的反对理由如下:1.这样逻辑容易混乱,不应该在Food信息中保存多余Category内的信息,否则同一种信息就在两处同时保存了,如果分类名字修改了,那么其下面的所有Food中都要跟着修改categoryName。

Z的查询顺序:categoryName-->category表-->categoryId-->food表-->food 信息
H的查询顺序:categoryName-->food表-->food信息

    请问Z和H谁对谁错呢?
加载中
0
天地一少鸥
天地一少鸥
抢自己的沙发
0
Xsank
Xsank
用mongo的唯一感受就是设计要求很宽松,没有关系型要求那么严格(我也十分想知道 mongo是不是也有正儿八经的设计规范),根据自己需求来,怎么方便怎么设计
0
亭舸翁
亭舸翁
个人比较喜欢Z的方案, 可以在应用里把category信息合并到food里避免客户端二次通信。如果有一天这种方式造成category查询过多,形成瓶颈了,可以通过缓存之类的解决,可以想象这种情况应该不会出现。而H的方案里,一旦category字段发生变动,例如增加一个category desc url,所有的food实体都要修改,而在项目初期,这种需求变动是很频繁的。个人觉得完全不必为了一丁丁点的性能造成这样结构的混乱。不是常说吗?make it work ,make it fast
今天星期一
今天星期一
回复 @天地一少鸥 : 那H这种设计更美必要了,效率上影响微乎其微
天地一少鸥
天地一少鸥
这个项目的前提是每个shop的分类都不多,而且食物也不可能超过100个。而且以后可能都不会存在category这个集合。弱弱地问问,多一个category集合有必要吗?
0
魔力猫
魔力猫

不要重复,不要冗余,保持简单。

H的需求本身就是胡来,因为现在根本没有这个问题,为了所谓的可能进行设计开发纯属浪费。而且还破坏了数据的单一性,造成冗余而难以维护。

魔力猫
魔力猫
回复 @天地一少鸥 : 你根本就没看我的回复。
天地一少鸥
天地一少鸥
回复 @魔力猫 : 有没有思考过数据库可以允许冗余呢?如果为了复杂而简洁,那这个简洁是没必要的。如果可以稍微有一点冗余,但却可以使设计很简洁,那么这个冗余是很有必要的。尽信书不如无书!
魔力猫
魔力猫
回复 @天地一少鸥 : 这和关系型没有任何关系,核心是冗余。NOSQL不是说把所有的原则都推翻,自己胡写。不要关系模型和追求冗余完全是两码事。关系型的数据仓库里面冗余到处都是,但是事务处理型的那么写就是找死。可见冗余和关系模型本身无关
天地一少鸥
天地一少鸥
这个项目的前提是每个shop的分类都不多,而且食物也不可能超过100个。而且以后可能都不会存在category这个集合。弱弱地问问,多一个category集合有必要吗?你了解过mongodb设计吗?你是从关系型转过来的吧?
0
marrysail
marrysail

如果确实没有太大必要,就宽松点,扩展性差点也无所谓,如果赶时间

Z的操作,设计会更加清晰,更OO一些。   看你的实际情况了,没有对错。

0
专业打酱油
专业打酱油
还好,我以为是这种{ CategoryId:1,food:[{},{}]}
天地一少鸥
天地一少鸥
是这一种: {"_id":ObjectId("1242343"),"CN":"客家菜","P":6, "CID":ObjectId("12223"),"I":"","L":10, "SU":"33_thumb.jpg","N":"腌面","BU":"33.jpg","U":123,"SN":"s", "SID":ObjectId("14523") }
0
Hobo
Hobo
H在胡搞
0
aiasfina
aiasfina

顶楼上...

H设计这个冗余,如果不是确实遇到瓶颈那就是在胡搞。如你第二点提到的,如果需要 category_name 和 categoryIconUrl 时,你问 H 那个 categoryIconUrl 怎么拿,一起挪到 food,还是查一遍?...

魔力猫
魔力猫
回复 @aiasfina : 这位只要看到反对H的都不高兴。
aiasfina
aiasfina
回复 @天地一少鸥 : 我想问下= =你所谓的mongodb设计是什么
天地一少鸥
天地一少鸥
这个项目的前提是每个shop的分类都不多,而且食物也不可能超过100个。而且以后可能都不会存在category这个集合。弱弱地问问,多一个category集合有必要吗?你了解过mongodb设计吗?你是从关系型转过来的吧?先了解mongodb再来评论。
0
天地一少鸥
天地一少鸥
以后会把category表都删掉的。看来楼上的各位都不懂mongodb的设计啊
天地一少鸥
天地一少鸥
回复 @专业打酱油 : 嗯,这个不错!谢谢!
专业打酱油
专业打酱油
还能把自己的评论当做最佳答案吗?其实这个问题看看这个:http://cn.docs.mongodb.org/manual/faq/developers/#when-should-i-embed-documents-within-other-documents PS,monogdb的文档改版以后比之前好了很多,新版本也比之前给力!
0
魔力猫
魔力猫

看来你就是H吧。被Z说教了跑这里发泄。你这么折腾直接找个excel好不,就是面向对象设计也是不允许Category的部分属性跑到Food中去的。

被说教了又给自己找辄,拿数量说事。

你的想法错误的地方在于冗余,而不是什么关系模型和NoSQL。NoSQL比关系模型灵活,就更需要在设计上自我约束,不要胡来。胡来的结果就是系统数据结构一团糟,根本没法维护。

请点赞
请点赞
不是发泄,是他要求发帖子的。category的所有东西都在food里面。
返回顶部
顶部