本人有过比较大的B2B2C商城开发经验，这里说一下自己的理解：
首先，分析题主的问题，你要设计的购物车是给一个什么量级的平台使用，如果使用Mysql数据库设计的话，规模不大，流量不多的情况下是完全没有问题的，但如果流量很大，用户量级上去了是行不通的。
所以，推荐根据用户登录和未登录态两种情况来做。
1.未登录时，可以采取cookie方式保存，因为存在客户端，可以缓解服务器压力。当用户登录账号后，从cookie取数据保存到redis里面。
2，用户登录了，保存购物车数据到redis中
那为什么采取这种做法，采用redis因为它保存在内存里所以速度很快，就算有很高的并发，可以采取redis集群的方案来解决，通常我们的做法都是把一些比较热的数据采用redis来保存。
后面你可能还会根据用户的购物车记录或者购买记录等等用户行为做一些商品推荐等推送的时候，redis集合的并交集谁用谁知道。
说回原题，我就说个简单思路。
产品：采用hash表存储，productID，price。。。等等
购物车：采用集合存储，因为集合的唯一性，保证一个orderId对应多个商品，再重复一下就是交并差集真的好用。。
再细分还可以设计购买物品关联的集合啊，购物记录的有序集合啊等等。
以上思路，集体细节还是结合自己的使用情况设计即可。

直接用第二种就行了，第一种拆分的做法有点多余。cart（ ）这个表在什么时候创建呢？创建用户的时候就创建，还是在用户第一次加入购物车的时候创建？无论在哪创建都有点不合适。第二种做法，加上state字段用于记录购物车商品状态（缺货，失效，删除等）。

个人觉得一张表就可以了,这是购物车表,存商品ID,购买商品数量,购买人ID就可以了,如果建一个购物车商品表,那么商品价格是按照加入购物车的价格来算么
-------编辑--------
还有其他字段,自行添加

首先声明：没有电商数据库经验。单从数据库的角度考虑，我个人觉得，如果每个注册用户就一个购物车来说，cart_item和user_cart没有本质区别。如果不考虑购物后购物车的物品转移问题，这两个表均可以。我的想法如下：
将此表修改为用户id与商品id的对应关系（不再留商品信息字段），用is_valid来识别物品是否已经结算（默认值为未结算） 或者结算后直接删除（就不再需要is_valid字段识别了）。用户与商品对应关系表保存衍生信息（购物数量，价格，状态等信息）

首先要明确你的购物车是一件商品还是多件商品合并
1、如果一件商品可以创建一张表，这样查询速度也会快很多。
2、如果涉及到购物车有多件商品的话，那么最好分开两张表（我自己的理解是如果有一对多关系，就分两张表）
其实这种设计也没有对错，只能说那个更方便，性能更好。个人推荐第二种

第一购物车的修改频率和使用频率过高，所以一般在购物车生成都会使用cookie或者h5的本地存储。
假如你一定要做数据表去保存购物车的话，数据量大的时候使用两张表（一张索引表，一张商品表）就可以了，假如数据量少情况下时候一张表就行

问题如果提的具体点就好了。购物车数据库表？