做电商十年，见过太多“精美”的策划书，翻开一看全是虚头巴脑的愿景，唯独缺了最硬的骨头：数据怎么存。尤其是卖衣服的，款式、颜色、尺码这三个维度一打架，表结构设计不好，后期改需求简直是扒层皮。这篇不讲空理论，直接拆解一个能落地的服装类电商底层逻辑，带你避开那些让开发团队崩溃的坑。
很多人写策划书时，习惯把“商品表”做成扁平结构，一行存一个SKU。这听起来没问题，但当你想统计“黑色L码”卖得比“白色M码”好多少时，你会发现数据散落在一堆冗余字段里。真实的业务场景里，服装的核心是SPU与SKU的分离。SPU是具体款式，比如“2023秋季新款羊毛大衣”，它拥有固定的款式名、主图、详细参数；而SKU是具体的销售单元，即“黑色/L码”、“白色/M码”。在数据库设计中，千万不要把颜色、尺码硬塞进商品详情表。正确做法是建立独立的维度表：color_id, size_id，或者更细化的variant_table。我见过一个客户，初期图省事，把“颜色”做成字符串存在主表，后期想按颜色筛选销量，写出来的SQL语句长到让人想吐，查询效率更是低得可怜。
再说说库存这个深坑。服装电商最头疼的就是超卖和缺货状态同步。很多小团队在策划阶段忽略“库存流水表”的重要性，只做一个stock字段做增减操作。这在并发量低时没事，一旦搞起秒杀或大促，数据库锁表能把你CPU打满。真正的避坑经验是：库存表必须独立，且要有lock_stock（锁定库存）和real_stock（真实库存）两个字段。用户下单锁定，支付失败释放，这样才能保证账目清晰。我之前帮一个服饰品牌重构数据时，他们的旧系统就是只有一层库存逻辑，每次大促完对账，财务能哭晕在厕所，因为根本查不出哪些单是退掉没释放的。
价格体系也极具欺骗性。很多人以为加个price字段就够了。错。服装的价格策略极其复杂：原价、折扣价、会员价、新人专享价、优惠券叠加后的到手价。在数据库层面，建议采用“价格规则表”而非单一价格字段。建立一个price_policy表，关联user_group（用户群体）和time_slot（时间段），通过逻辑计算最终成交价。这样即便运营临时调整策略，也不需要动核心商品表，只需要修改规则记录，前端即可实时生效。这种解耦设计，在《电子商务网站建设策划书》中应当作为核心亮点呈现，它体现了系统的可扩展性。
此外，别忽视“日志表”。商品浏览日志、收藏日志、加购日志，这些看似杂乱的记录，其实是做精准营销的弹药。很多策划书只关注“买”，忽略了“看”。如果数据库里没存下用户昨天看过哪件衬衫、犹豫了多久，你的推荐算法就是一张白纸。设计时，日志表要考虑到分库分表的可能性，因为日志增长速度远超交易数据。
最后提醒一点，写策划书不是为了应付老板，而是给开发看的“图纸”。如果你的数据库设计部分含糊其辞，只说“采用MySQL存储”，那这份文档的价值就归零了。清晰的ER图（实体关系图）、具体的字段类型定义、索引策略建议，这才是能打动技术负责人、让项目顺利推进的硬通货。别让你的创意死在落地的泥潭里，从一张靠谱的表开始。
