15、数据库继承策略与多态关联实现

数据库继承策略与多态关联实现

1. 物理继承类型选择

在确定使用哪种物理继承类型（单表继承或多表继承）时，关键在于子类是否实际共享物理数据。若子类之间共享全部或大部分数据，单表继承是合适的选择；若类之间没有太多共同数据，则多表继承（甚至在数据层不使用继承）是正确的选择。

单表继承虽然内置方便，但在数据重叠较少的情况下使用会带来问题。数据模型会变得混乱，许多列仅在特定情况下才会填充；应用层会充斥着表中每个物理列的 getter 和 setter 方法，从逻辑模型的角度看，这些列及其访问方法本不应存在。此外，单表继承还会将数据层的物理模型渗透到应用的逻辑模型中。

单表继承还有另一个缺点：类名会保存到数据库中以标识每行的类型，随着应用的成熟，这种代码与数据的关联可能会产生意想不到的后果。使用单表继承会使类名基本固定，若要更改类名，必须更新所有引用原始类的记录。在拥有数百万条记录和活跃用户的生产数据库中，进行这样的更改几乎是不可能的，可能需要数小时，在此期间，网站可能会变慢甚至无法工作，因为单表继承关系无法解析。

2. 单表继承示例

以信用卡支付模型为例，之前信用卡实现了一种策略模式，信用卡对象是常量，其方法可应用于订单以完成任务，如处理付款。这次采用不同的方法，将支付信息从订单类中分离出来。每个信用卡支付对象将包含处理交易所需的数据，如信用卡号、过期信息以及授权交易所需的任何地址数据。

对象本身可以处理交易，基于自身的本地数据进行操作。但不会有信用卡支付对象，实际对象将是其子类（万事达卡支付、维萨卡支付和美国运通卡支付）的实例，这些子类将定义处理该类型交易的特定行为。由于用户处理信用卡支付所提供的信息类型与支付类型无关，这