关于数据库的实际设计问题问一下

Question

我想问一下各位大侠在实际项目中怎么处理多对多的表关系？
  是由关系表中处理（记录两边id的对应关系），还是在量表中的一个较为具体的业务表中记录另一个表的id串呢？
  比如设备表和负责人表，一种是建立设备表和负责人之间的关系表这个就不说了，另外一种是设备表中记录负责人的一串id，哪种好呢？另外项目中有一些基础信息需要维护，比如楼，层，设备类型，设备品牌，这些信息都具有很少的属性，单独建表太浪费了，我就把这些信息全部都放到了一个表里，但是这样的话值与值之间出现的多对多的关系怎么处理呢，比如，设备品牌与设备类型之间的多对多的关系，比如dell有服务器，个人pc等，服务器也有dell、hp、ibm生产；还有多级的这种关系，比如洲、国家、省、市，这样的关系又怎么处理呢？

Answer 1

这个要看具体情况。 一般来说严格一些的设计，或者数据比较在的数据库， 则完全按规范设计。一个实体一个表。结合 “比如，设备品牌与设备类型之间的多对多的关系，比如dell有服务器，个人pc等，服务器也有dell、hp、ibm生产；” 这个例子，常规的设计是设备表（设备编号，品牌，类型，）
设备品牌表（品牌ID，）
设备类型表（类型ID，）
品牌类型表（品牌ID，类型ID，）还有一种设计方法，那就是每个品牌下的类型都很少相同，即产生的重复冗余数据不多的情况下。设备表（设备编号，品牌，类型，）
设备品牌表（品牌ID，）
设备类型表（类型ID，品牌ID,）

Answer 2

这个网上有很多例子。 完全按范式的设计方式如下 。洲表（洲ID，名称）
国家表（国家ID,国家名称，洲ID）
省表（省ID，名称，国家ID）
市表 （市ID，名称，省ID）但通用一些的，加入部分冗余以提高查询效率和减轻编程则可以合并部分表。国家表（国家ID,国家名称，洲I名）
省表（省ID，名称，国家ID）
市表 （市ID，名称，省ID，国家ID）

Answer 3

这个我可能描述的不太正确，其实我想描述的是一种非树性结构，可能有回环。你得答案已经很详细啦，可是对于基础信息是这样，就是可能由用户自定义表单，那这些自定义表单现在采取的是动态分表，和动态orm。但这些自定义表单里面有一些基础信息也是可自定义的，比如客户可能需要增加设备产地这样的属性。所以我才萌生了把所有基础信息都放到一个表里，然后又一个基础定义表来定义他们的意义。除此以外新建设备产地时，他的值可能与其他的基础值还有关联，比如对于服务器可能有中国，马来西亚，美国，日本；但对于F5可能只有美国，欧洲。这样的需求有办法实现吗？