Discuz! 目前在用Discuz!3.2给人做一个东西，需要增加很多自定义字段，其中涉及到要和其他帖子产生关联。详情如下：
A栏目名称是“品牌”，B栏目的名称是“商品”，现在商品栏目中新增的帖子，需要选择一个“品牌”的帖子做为自己的“品牌”。（这不是一个商城，用dz来做肯定是有特殊情况，所以就不要提商城的事儿。）dz中每一个帖子都有一个fid字段和一个name字段，在这个选择“品牌”的过程中，考虑到以后访问量等因素，我应该在“商品”添加的时候同时添加fid和name到“商品”附表，这样系统查询的时候就一并查询出来；还是只添加fid，然后在需要显示name的时候，再次向数据库查询fid？有4个地方需要在展示"商品"帖子的时候显示"品牌"帖子的name。
对于高并发访问的数据库设计完全没得概念，所以还请各位DB大牛不吝赐教。谢谢啦。
---------------补充----------
总结来说就是，冗余两个字段，每个字段的长度在10个字符串以内。但是可以一次性查询出来，不冗余这两个字段，则需要第二次查询。考虑到高并发等情况，我该怎么选择？
----------------再次补充-------------------
经过和朋友讨论以后，在基于DZ框架的背景下，最终还是采取冗余的方法，考虑到初期数据量并不是非常大，冗余，对于数据库的影响不大，可以节省很多开发时间，直接使用DZ自带的方法就可以查询到内容，就无需再次修改PHP。后期数据量非常大的时候，再来删除冗余字段，或者做其他更规范的数据库处理。
如果name不经常变的情况下，且关联name处很多。可以冗余存储下字段。
否则就只记录关系标识即可。
即，表A中有指向表B的外键字段，那表A中是否应该再增加表B的常用字段（如标题），以减少Join。
我的做法是：不用。
在数据量没达到十万级别的时候，这样基本没问题。
如果数据量和并发数都上来后，也不会变动A或者B，而是会在前面加一个ETL层，其中有Join好的AB（可以是数据库，也可以是别的缓存层）。ETL层和数据库层之间用MQ打通数据同步机制。
引用来自“方棱”的评论
即，表A中有指向表B的外键字段，那表A中是否应该再增加表B的常用字段（如标题），以减少Join。
我的做法是：不用。
在数据量没达到十万级别的时候，这样基本没问题。
如果数据量和并发数都上来后，也不会变动A或者B，而是会在前面加一个ETL层，其中有Join好的AB（可以是数据库，也可以是别的缓存层）。ETL层和数据库层之间用MQ打通数据同步机制。
使用DZ开发是否合适先不考虑。
对应数据库设计，我只说一个原则，那就是除非你真的有足够证据证明按照规范范式设计数据库会有性能问题而且这个性能问题无法解决，或者有足够证据证明你写入的数据是永远不会被修改的，否则不要轻易用性能作为借口反范式设计。
随便拿数据库表当excel用，有可能引发的问题远远超过所谓少连接一个表剩下的东西。
数据库对于表连接的处理能力其实非常强大，关联几个十几个表，只要数据库结构设计合理，其实是非常轻松的事情。