「这个二期再说。」项目里这句话说出口的次数，和二期真的只停留在「再说」的概率，基本成正比。需求是会长出来的，做开发的都懂。但数据库设计如果在一期就死死焊住，二期加需求时只能推倒重来，客户的预算和工期一起遭殃。留后路这件事，有几种成本极低的做法。
软删除，几乎零成本
多数业务数据都有「不能真删」的需求：订单删了财务对不上账，会员删了历史记录全断。建表时统一带上is_deleted字段，查询时过滤掉即可。一期就算用不上也建议加上，二期想从硬删切软删，要迁移历史数据，那才是真折腾。一个字段三分钟的事，别省。
一对多的关系别做成逗号串
典型反面案例：订单表里一个goods_ids字段存「12,35,88」。一期只有一个商品也能跑，二期要拆明细、做报表、按商品统计销量，这种设计直接废掉，只能迁移数据重建。凡是「将来可能不止一条」的关系，一开始就建子表，哪怕眼下每单只有一条记录，SQL写起来也舒服。
模块之间留缝，别焊死
会员模块和积分模块，通过会员ID关联，别把积分字段直接堆进会员表。模块解耦的判断标准很简单：砍掉一个模块，别的表结构会不会受影响？会，就是焊死了。另外给关键业务留一张操作日志表，将来出任何问题都有据可查，这是所有改版里最不会被嫌多的一张表。
举个留后路省钱的例子。一家做企业服务的客户，一期只做了人工审核，但建表时把审核记录拆成了独立的审核表，字段里留了审核人、审核意见、审核时间。半年后要加自动审核和复核流程，表结构一个字没改，只在上面加了层代码，二期工期比预期省了一半。表留了缝，改的只是代码，这就是后路的价值，平时看不见，关键时真值钱。
两条建议：一期表结构评审时，就让开发逐表说明「这里将来怎么扩」，说不上来的地方就是隐患；二期开工前先做一次表结构体检，确认哪些能复用哪些要重构，别默认全推倒。比格网络接二期项目时，会先出一份数据库设计评估，哪些留哪些改写得明明白白，客户花小钱，省的是大改版的冤枉钱。
