继承和数据库设计

OOP中我们经常会遇到继承的问题，在面向对象的语言中表示继承是很简单的。比如Java、Ruby。

但是如果我们需要每个类对应关系数据库的表结构也能够反映出继承关系呢？

 

假设有一个公司员工俱乐部系统，有足球俱乐部、篮球俱乐部、读书俱乐部，我们已经有如下类结构

 

class Club {

   String name;

   Time createTime;   

}

 

class SportsClub extends Club {

   Integer teamSize;

}

 

class FootballClub extends SportsClub {

  Integer footballQuantity;

}

 

class BasketballClub extends SportsClub {

  Integer basketballQuantity;

}

 

class ReaderClub extends Club {

   Integer bookQuantity;

}

 

这种结构的数据需要存储，那么有几种策略：

1 用单表继承结构存储：

clubs

(

name

team_size

footboall_quantity

basketball_quantity

book_quantity

create_time

)

 

这种方法最大的好处在于将所有关系都放在一个表，表修改简单并且不需要表连接。

坏处在于浪费空间，留下了很多空字段，当然大部分数据库的压缩算法节省了空间，并且如果数据量大，那么访问此表成为瓶颈。这个例子中footboall_quantity、basketball_quantity和book_quantity 中只有一个字段是有数据的。

 

2 用实际对象的具体结构存储：

football_clubs

(

name

create_time

team_size

footboall_quantity

)

 

 

basketball_clubs

(

name

create_time

team_size

basketball_quantity

)

 

book_clubs

(

name

create_time

book_quantity

)

 

这个方法也不需要表连接，能够从一个表就得到整个对象所有字段数据，相对于第一个方法而言避免了浪费空间。

但是这个策略的缺点就是如果父类结构发生了变化，那么所有子类都需要进行同样的变化，如果继承关系修改了，修改可能更为复杂。所以如果逻辑关系稳定的类比较适合用这种方法。

 

3 每个数据库表存储一个层次

clubs

(

name

create_time

)

 

sports_clubs

(

team_size

)

 

football_clubs

(

football_quantity

)

 

basketball_clubs

(

basketball_quantity

)

 

reader_clubs

(

book_quantity

)

 

这种表结构是最直接反映类结构的策略，存储空间占用最少，相对并且容易修改层次结构。

但是它需要读多张表来获取单独的一个数据，如果需要增加一个数据，也需要操作多张表。

 

这些策略都是访问速度和数据重复的折中。并没有谁好谁坏，实际应用中应该根据具体的应用来采用不同的策略。