浅析关联设计

【范式】

      比较理想的情况下，数据库中的任何一个表都会对应到现实生活中的一个对象，如球员是一个对象，球队是一个对象，赛程是一个对象，比赛结果又是一个对象等等，则就是范式。

【关联设计】

       对于关联设计可以理解成表和表之间要有关联关系，在对表查询时经常使用关联查询。

       补充：关系数据库的来源：对一个事务操作要从多个表中读。

       如2014巴西世界杯这个表空间中要有球员表、赛程表、比赛结果表，比赛结果表要关联比赛的队伍名字、球员的名字最后关联一个比赛的结果，这就是一个简单的关联关系。至于为何要设计成范式，也很好理解，这是为了不冗余存储数据，同一场比赛的结果就不用重复的存储了，如巴西对德国0:0和德国队巴西也为0:0（因为是同样的两支队伍，结果必然是一样的），这样就可以只存在一行数据了，结果也就是保持了数据的独立性。

【不良好的范式、关联设计举例】

       如果不良好的范式、关联设计会引发关联的成本的问题，举个例子，如果两张表的成本都很大，来做等值连接和不等值连接时将会有很大的成本问题。如从世界杯的进球球员中去关联到该名球员在俱乐部中一个赛季的表现情况时，如进球数、犯规数、抢断数等等一些列数据时，而这个数据是存在于一个较大的表中的，对于这两张表的关联成本将会很大。因为世界杯中进球球员的一行记录有可能对应赛季表中的很多行数据，而每一个球员都是这样，第一个表中的一行数据对应于第二个表中的很多行数据，这种交叉的链接过程中，成本是相当高的。这也就引出了，目标比较流行的技术趋势，反范式。

【反范式】

       反范式，打破旧有的良好设计，而故意使用存在冗余的数据。

举个例子，如下图

表1：

表2

            如上，表1是世界杯球员统计数据，表2为球员在俱乐部中的表现情况。为了避免球员重名情况，表2使用了ID号作为标识。现在想要查看世界杯表现优异有进球的小罗在俱乐部的表现情况，即要关联世界杯有进球的球员在俱乐部中的表现情况时，要通过第一张表进行关联，先要知道小罗的ID号，再查到对应的俱乐部表现情况。表1中的一行数据要对应到表2中的1列数据，表2中的1列数据也要对应表1中的1行数据，在以万条计的两张大表中，这个关联成本是相当高的。虽然两张表符合了良好的范式、关联性，防止了冗余、防止了冲突，但在性能上就非常差了。对应的改善做法就是不写ID号，而是直接填写球员的名字，如果有重名在后台数据库做一个标识。这样想查询某球员俱乐部表现情况时，就直接到表2中去查询相应的数据信息即可。从设计上出发，没有一个好的范式、没有一个好的关联设计。但从性能上分析，比一个良好的范式、关联设计体现了更好的性能。