数据库映射
映射的主要目的是将面向对象的编程语言中的对象模型（如类和对象）与关系数据库中的表和行之间建立联系。这是因为面向对象编程和关系数据库使用不同的数据表示方式，直接交互可能会导致数据不一致和复杂的处理过程。
TPH（Table Per Hierarchy）每层次一个表：
在这种策略下，整个继承层次结构共享一个数据库表。所有类的属性都映射到这个单一的表中，并通过一个标识列来区分是哪一个具体的子类。
优点：数据访问快；管理方便；没有表连接。
缺点：表会变得非常宽大；某些列可能会为空。
例子：假设你正在开发一个涉及员工管理系统的应用，其中有不同类型的员工如全职员工、兼职员工和临时工。所有类型的员工共享一些共同的属性（例如姓名、员工编号），但也有各自独特的属性。在这种情况下，使用TPH策略可以将所有员工的数据存储在一个表中，通过一个“员工类型”列来区分不同类型的员工。
适用场景：继承层次结构较浅，且子类具有较多相似属性。想要快速访问数据且避免复杂的表连接操作。
TPC（Table Per Concrete Class）每具体类一个表：
在这种策略下，每个具体类都有其独立的表，表中存储该类的所有字段，包括从父类继承的字段。
优点：表结构简单，清晰；每个表只包含相应类的属性。
缺点：在查询父类时需要执行多个表的联合操作，性能可能受影响。
例子：假设你有一个图书馆系统，其中有图书、杂志和DVD，它们分别继承自一个父类“媒体”。每种媒体都有自己独特的属性，例如图书有作者和ISBN，杂志有出版期和期号，DVD有导演和长度。使用TPC策略，每种媒体类型都有自己的表，存储其特定的属性。
适用场景：每个具体类具有独特的属性集合，且查询往往以具体类为主，不需要频繁跨类查询。
TPT（Table Per Type）每类一个表：
在这种策略下，父类和子类都有各自的表，子类的表包含自己的字段和一个外键，用于引用父类表中的记录。查询时需要表连接。
优点：表的设计更符合数据库范式；避免了数据冗余。
缺点：查询性能可能不如TPH高；涉及多表连接，复杂度增加。
例子：假设你有一个在线商店的系统，其中有不同类型的产品如电子产品、服装和家具。每种产品都有共同的属性（例如产品名称、价格），但也有独特的属性（例如电子产品有品牌和型号，服装有尺寸和颜色，家具有材料和尺寸）。使用TPT策略，父类和子类各有一个表，查询时通过表连接获取完整的产品信息。
适用场景：继承层次结构较深，且子类具有独特的属性。希望表结构更符合数据库范式，避免数据冗余。