表关联字段的存放的设计

一般的数据库表设计，表代表的都是一个实体对象。对象和对象之间都有一些关系，而这些关系在表的设计中，基本就是通过关联字段来体现的。

先来说说对象和对象之间关联的设计。举一个简单的例子：班级和学生，2个对象；班级是一张表，有一个主键CLASS_ID；学生也是一张表，有一个主键 STUDENT_ID；那么一般的设计，会在学生表中添加字段CLASS_ID，表示这个学生是哪个班级的，这是一个最简单的设计。需要说明的是，一般还会在学生表的CLASS_ID上添加一个索引，这主要是考虑表关联时候的查询效率。

接下来，介绍一下一个对象，由于拆表导致的关联设计。邮件信息的设计：我们知道一封邮件会有多个附件，那么把附件放入邮件主体中就不太合适，由于附件的查询都是通过主邮件来查询的，所以 我们一般会把邮件表T_EMAIL和附件表T_EMAIL_ATT分开设计，T_EMAIL的表的主键EMAIL_ID，这个字段通常会放入在附件表中，并且在附件表的EMAIL_ID字段上添加一个索引。由于邮件产生的时候，主键就已经确定，这个主键是无需修改的，那么放入附件表的主键就永远不会修改，这样不会出现为了维护数据一致性的问题。

第三个，就是我们这一次遇到的案例，商品设计的案例。一个商品，只有一个描述，当然也是可以没有描述的。如果商品表是T_GOOD，主键GOOD_ID；商品描述表T_GOOD_DESC，主键GOOD_DESC_ID，由于最多是1<->1的关系，那么设计者就面临了两个选择：是把good_id 放入描述表中，还是把good_desc_id放入商品表中 ？ 在我看来的一个原则，就是冗余编号的代价。让我们来想一想：（1）如果把商品编号GOOD_ID放入商品描述表T_GOOD_DESC中，那么我们知道商品是编号是一定不会修改的，所以这个冗余是没有一致性维护代价的。（2）如果把商品描述的编号GOOD_DESC_ID放入商品中，那么当这个描述被删除的时候，实际上是有同步数据的代价的，需要把这个商品描述对应的商品的字段设置为NULL值。还不仅仅如此，所有商品和描述的关联其实都需要使用LEFT JOIN，并且在商品中的GOOD_DESC_ID也必须是一个NULL值，仔细想来，这种方案当然不够好。所以在这个案例下，我们采用（1）的方案。 这里可以看出一个设计原则，当一个对象由于某些原因被拆开，基本上会在属性对象表中冗余主对象的表。

第四个案例，就是多个关联关系的案例。比如说：工作记录表，在审核的时候，我们会记录审核的主题信息id，在投诉时候，又会记录投诉主体信息的id，也就是工作记录表会对应多个对象，这种情况下的设计通常使用两个字段：relate_type,relate_id ；也就是不同类型，对应不同表的主键。

通过这四个案例，大家一定对这个关联字段的存放设计有了比较清晰的思路了。 最后需要强调一下，关联字段一般都会添加索引。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/617982/viewspace-2136637/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/617982/viewspace-2136637/