前两天和一个做后端的朋友聊天，他吐槽说现在业务逻辑越来越复杂，数据库表结构改来改去，每次加个新功能，都要改一堆 SQL 语句，搞得头大。我让他试试用面向对象的思想去设计数据库，他愣了一下——数据库还能继承和多态？这哥们儿干了八年开发，居然从来没想过数据库和类之间能玩出这种花样。
其实仔细想想，数据库的本质就是存储和管理数据，而类是对现实世界事物的抽象。这两者之间天然就存在某种映射关系。从最早的层次数据库、网状数据库，到后来的关系数据库，再到现在的 NoSQL 和 NewSQL，数据库的每一次进化，都在尝试更好地表达数据之间的复杂关系。而类的继承与多态，恰恰是解决这种复杂关系的有力武器。
先说说继承。你想想，现实世界里的事物从来不是孤立的。猫是动物，狗也是动物，它们都有名字、年龄，但猫会喵喵叫，狗会汪汪叫。在数据库设计里，如果你建一张动物表，再分别建猫表和狗表，那名字和年龄字段就得重复写两遍。这不是浪费，而是给自己埋坑——哪天想给动物加个体重字段，你得改三张表。用继承的思路，把公共字段抽到父表里，子表只存自己的特有字段，这才是正解。PostgreSQL 支持 table inheritance，Oracle 有对象类型，连 MySQL 也能通过外键和视图模拟出继承的效果。
更妙的是多态。多态的意思是，同一个接口，不同的实现。放到数据库里，就是查询父表时能同时拿到所有子类的数据。比如你有个订单系统，订单可能是普通订单、团购订单、秒杀订单，它们的处理逻辑完全不同。如果用多态的设计，建一张订单父表存公共字段，再建三张子表存各自的特殊字段，查询时只需要查父表，数据库会自动把子表的数据拼回来。这种设计，比用一堆 if‑else 判断订单类型要优雅得多。
有人可能会说，我用 JSON 字段不就行了？把所有字段塞进一个字段，想加什么加什么，多灵活。这确实是很多人的做法，但问题在于，JSON 字段像个黑箱子，数据库不知道里面有什么，没法建索引、做约束，查询性能会大打折扣。而继承和多态的设计，所有字段都是明确定义的，数据库能优化查询，能保证数据完整性，这才是正经的工程思维。
再说个实际案例。我去年帮一家电商公司重构商品系统。他们原来的设计是每个品类一张表，手机一张表，电脑一张表，家电一张表，结果搞了三十多张表，每张表字段还不一样，维护起来简直是噩梦。后来我们用继承的思路，建了一张商品基础表，存名称、价格、库存这些公共字段，然后每个品类建一张子表，存各自的特殊字段。查询时，一条 SQL 就能拿到所有商品的公共信息，需要详细数据时再查子表。重构后，代码量减少了 40%，查询性能提升了 30%。
这种设计还有个好处，就是扩展性。公司业务在发展，随时可能加新品类。以前加个品类要新建一张表，改一堆查询逻辑；现在只需要新建一张子表，继承父表的所有字段，再加上自己的特殊字段就行。业务代码几乎不需要改动，这就是多态带来的灵活性。
当然，继承和多态也不是银弹。如果业务逻辑极其简单，所有数据一张表就能搞定，那搞这些花活就是过度设计。还有一个问题是性能：继承查询通常需要表连接，数据量大时会有性能损耗。但架构设计本身就是 trade‑off。想要灵活性，就得付出一点性能代价。关键在于业务的核心诉求是什么。
其实数据库的进化史，就是人类对数据关系认知不断深化的过程。从最初的文件系统，到关系模型，再到对象关系映射，每一步都在尝试让我们用更自然的方式描述世界。类的继承与多态，正是这种认知进化的产物。它们不是编程语言才有的概念，而是解决复杂问题的通用思维工具。
说点实在的。如果你现在还在用一张大表装天下，或者搞一堆冗余字段，不妨停下来想想，你的数据模型真的合理吗？试着用继承和多态的角度重新审视数据库设计，也许会有意想不到的收获。毕竟，数据库这个老古董，比想象的要灵活得多。就像我那个朋友，尝试用继承设计数据库后感慨说，原来数据库也能写出诗来。
