用户数据存储疑问：电商平台后端用数组存储是否合理？

一、你给出的存储方式存在的问题 #

首先你的代码存在语法错误——用数组[]定义用户，但内部是键值对结构，应该改成对象{}，正确写法如下：

const user = {
  userName: "john",
  userWallet: 122,
  userProfilePic: "https://blbabablabl.com/ewxase",
  userCart: [
    {
      productName: "Air Jordan 1",
      price: 280,
      productImage: "https://www.blablabla.com/image"
    },
    {
      productName: "Louis Vuitton Bag",
      price: 900,
      productImage: "https://www.blablabla.com/image"
    }
  ]
}

即便修正语法，这种存储方式在电商场景下也存在明显问题：

• 性能浪费：每次获取用户基础信息时，都会连带加载整个购物车数据，若用户购物车商品较多，会大幅增加带宽消耗和加载时间。
• 维护成本高：如果商品信息（如价格、图片链接）更新，需要遍历所有用户的购物车数据逐一修改，极易出现数据不一致。
• 并发风险：多个操作同时修改购物车时，需要更新整个用户对象，容易引发并发冲突，增加逻辑复杂度。

二、企业级电商场景的常用存储方案 #

1. 关系型数据库（如MySQL、PostgreSQL） #

采用分表关联的解耦设计：

• 用户表：存储用户基础信息（userId、userName、userWallet、userProfilePic等）
• 商品表：存储商品核心信息（productId、productName、price、productImage、库存等）
• 购物车表：作为关联表，存储userId、productId、购买数量、加入时间等字段
• 优势：数据无冗余，商品信息更新只需修改商品表，所有关联的购物车数据会自动同步；查询灵活，可通过JOIN操作获取用户购物车详情。

2. 非关系型数据库（如MongoDB、Firebase Firestore） #

结合非关系型数据库特性，常用两种设计：

• 子集合模式（Firebase推荐）：在用户集合的每个文档下，创建cart子集合，每个购物车项作为子集合的单独文档，包含productId、购买数量、加入时的价格快照（避免后续商品价格变动影响用户加购记录）等字段。
• 独立集合模式：单独创建carts集合，每个文档存储userId、productId、购买数量、加入时间等信息，通过userId关联用户。
• 优势：避免嵌套过深导致的性能问题，更新购物车只需操作单个子文档或独立文档，并发冲突更少；可灵活存储购物车临时数据。

三、学习后端数据存储的方向 #

• 先掌握数据库设计基础：了解数据库范式（第一、第二、第三范式）和反范式的适用场景，明确何时该解耦、何时可冗余数据。
• 针对你正在使用的Firebase：重点看官方文档里的数据结构设计最佳实践，里面有专门的电商场景示例（如购物车、订单设计）。
• 阅读经典数据库书籍：比如《数据库系统概论》，帮你建立系统的数据库知识体系；也可找电商场景的数据库设计案例教程，跟着实操理解。
• 参考大厂技术分享：很多大厂会公开电商系统的数据库设计思路，比如如何平衡性能与数据一致性，这类内容能帮你理解企业级设计逻辑。

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