如何为自主开发的Django线上商城web应用设计所需数据库模型

第一步：从已完成的前端倒推所需实体 #

你已经做完前端开发，这是梳理模型的最好依据，不用凭空想：

• 逐页拆解所有需要动态渲染的元素：比如商品详情页的名称、价格、规格、分类、轮播图、评论，购物车页的商品条目、数量、选中状态，订单页的收货地址、支付状态、物流信息，所有需要从后端取数的字段全部列出来，再按属性归类到不同的实体。
• 梳理所有前端交互对应的操作：比如用户注册、加购、下单、退款、评论这些操作，涉及到的关联关系会对应到模型的外键、多对多字段配置。

第二步：通用商城核心模型清单（可根据你的功能裁剪） #

以下是Django开发商城最常用的基础模型，核心字段可以直接参考：

• 用户相关
  • User：如果不需要特殊扩展直接用Django自带的auth.User，需要加手机号、头像等信息可以继承AbstractUser扩展，核心字段：phone、avatar、default_shipping_address（外键关联地址模型）
  • ShippingAddress（收货地址）：核心字段user（外键关联用户）、receiver（收件人）、phone、province/city/district/detail（四级地址信息）、is_default（是否默认地址）
• 商品相关
  • Category（商品分类）：核心字段name（分类名）、parent（自关联外键，实现二级/三级分类）、icon（分类图标）、sort（排序值，控制前端展示顺序）
  • Product（商品SPU，通用属性单元）：核心字段name（商品名）、description（商品详情）、category（外键关联分类）、sales（销量）、on_sale（是否上架）、create_time（上架时间）
  • ProductSku（商品SKU，库存单元）：核心字段product（外键关联SPU）、specs（规格组合，比如"红色+256G"）、price（售价）、original_price（划线原价）、stock（库存）、cover_image（SKU主图）
  • ProductImage（商品轮播图/详情图）：核心字段product（外键关联SPU）、image（图片资源）、sort（排序值）
• 交易相关
  • Cart（购物车）：核心字段user（外键关联用户）、sku（外键关联SKU）、count（商品数量）、selected（是否选中结算）
  • Order（订单）：核心字段order_sn（唯一订单号）、user（外键关联用户）、shipping_address（冗余存储收货地址，避免后续地址修改影响历史订单）、total_amount（订单总金额）、pay_amount（实付金额）、pay_status（用choices定义待支付/已支付/已取消/已退款）、order_status（用choices定义待发货/已发货/已签收/已完成）、create_time（下单时间）、pay_time（支付时间）
  • OrderItem（订单商品条目）：核心字段order（外键关联订单）、sku（外键关联SKU）、count（购买数量）、purchase_price（冗余存储购买时的单价，避免后续商品改价影响历史订单）、specs（冗余存储购买时的SKU规格）

你可以根据自己的前端功能按需新增模型：有评论功能就加ProductReview模型关联用户和商品，有优惠券功能就加Coupon、UserCoupon模型，权限相关直接用Django自带的Permission、Group即可，不用额外开发。

第三步：校验和优化建议 #

• 先给模型加必要的约束：比如订单号必须唯一、同一个用户同一个SKU在购物车里只能有一条记录，这些可以在模型的Meta类里加unique_together或者constraints配置，避免生成脏数据。
• 不用硬卡数据库三范式：类似订单冗余存储收货地址、购买单价的设计，虽然有数据冗余，但能避免关联查询历史数据出问题，在商城场景下是完全合理的，可以根据你的查询需求灵活加冗余字段。
• 写完模型后先执行makemigrations和migrate生成表结构，手动造几条测试数据，验证是否能支撑所有前端页面的渲染和交互需求，缺字段或关联关系随时调整即可，不用追求第一次设计就完全完美，小步迭代是最适合新手的方式。

内容的提问来源于stack exchange，提问作者gerard