开发者社区> 问答> 正文

mongo设计原则问题

情景假设:假设每个饭店内都有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谁对谁错呢?

展开
收起
落地花开啦 2016-02-20 12:00:16 1974 0
1 条回答
写回答
取消 提交回答
  • 喜欢技术,喜欢努力的人

    不要重复,不要冗余,保持简单。
    个人比较支持Z的方案, 可以在应用里把category信息合并到food里避免客户端二次通信。如果有一天这种方式造成category查询过多,形成瓶颈了,可以通过缓存之类的解决,可以想象这种情况应该不会出现。而H的方案里,一旦category字段发生变动,例如增加一个category desc url,所有的food实体都要修改,而在项目初期,这种需求变动是很频繁的。

    2019-07-17 18:45:15
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
MySQL 开发规约实战 立即下载
低代码开发师(初级)实战教程 立即下载
阿里巴巴DevOps 最佳实践手册 立即下载