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谁对谁错呢？