看了上面那两张图应该可以看出其中一对多的关系
第一幅图是一个比较典型的一种,在这里,第一张图中我列出了两种结构,一种是把一对多的关系以字段的形式表现出来,这种情况下我这形式表示,是因为地区是有限的,所以可以设计在一张表中,也可以分散在两张关联表中,这样种设计分别带来两种问问题!
第一幅图第一:同在一张表中。这种情况好优点是只需要读取一张表,即可以读取出一个用户的相关信息,但问题也同样存在,当需要搜索某一区域的用户是,我们不知道匹配哪一个字段,要么是用or来比较每一个字段,要么就是先从需市表查出该地区id 的级数,在根据级数比较相应的字段,总的来说,查询很麻烦。
第第一幅图二个种情况:在不同的表中,以关联表体现,这种结构在查询时变得比较容易,但是需要联结查询,而且如果我要显示用户的国家>省份>市县>地区的话,同样比较麻烦一点,我需要读出四条关联的记录。所以各有优缺点,但个人更喜欢这种!
第二幅图:这幅图是通过一个中间映射表来共用一个表中的数据,比第一幅图的要复杂一些,就是有一个图库表的概念,这个表中存储了所有用户的上传图片信息,这些国片可以是任何信息的图片,可以用于产品,可以用于相册,分别通过图示的相应的Map表来实现,但是同样是在显示一条数据的时候查询记录时比较麻烦一些,我们需要去map表中读出图片的id,再通过id 去t_Pic表中读取相应的地址,这个过程有点漫长!
问题:这两张图中讲到的三种设计方式的问题有没有更好的方式能够解决呢?还有就是第一张图中可以看出来,我增加了城市名称的冗余,是为了少查询一张表,直接可以得到城市名称,大家觉得这样设计可以吗?有必要吗?
在这种结构设计方面大家都怎么设计的,在读取查询显示方法怎么很好的处理这些关系的,谢谢大家分享先!
t_user2中的冗余字段,似乎没有什么必要,城市的数量也就那么多几百个,可以缓存到程序中,在需要显示名字的时候,根据id直接在缓存中找到名字就可以了。
冗余请在特别必要时使用