用户购买商品表应该怎么设计？

第一种表可以根据时间将记录作废
或者归纳到分表，2015 2016 2017 订单
第二种表简直是灾难

查询下用户订单表不就可以判断用户是否购买过商品了吗？

select * from order where user_id=123 and item_id=456 limit 1

同时给个 user_id 与 item_id 组合 index 就好了

第二种是反模式，不推荐。数据如果脏了，那么爆炸。

还有第二种这样的操作啊

@bxb100 初学，见笑了

用 json 字段，如果是 5.7 的话

100 万…很少…

请看数据库设计一二三范式

顺便 100w 数据完全不多啊

100 万....很少的 , 目前公司一个库单表 800 万没啥问题 . 主要是索引设计好

第二种设计太可怕了

正被要求第二种设计的路过，都是累

看了下，楼上还没人说到点子上，我说两句。

第一种方法是初学者就会用的方式，后续数据库维护也简单。

第二种其实思路是对的，因为接下来你还要根据需要作为查询条件去取那些商品数据的，你需要快速一步到位的得到 id 逗号分隔这种数据，但因为逗号分隔的数据内容可能很大，有可能空也可能买的太多导致 varchar(3000)都不够用，就不能用定长字段，所以数据量大了查询会慢，而且后续维护起来麻烦。

所以，如果不想找太多麻烦就用第一种，如果想优化设计，可以用第二种的思路，只拿第一种做原始数据，但查询的 id 逗号分隔数据用 nosql 或文件目录结构来存放“缓存”，需要更新维护时先修改原始数据，然后更新“缓存”，也称不上楼上有人说的灾难，想运行快就要付出代价。

有个设计原则，就是别什么烂活都交给关系型数据库，这种数据库是种代价高昂的数据存储方案，相对而言速度也不是很快。

另外每一部分用什么方案，跟服务器的假设和配置方案也有关系，比如 cpu 和内存还有磁盘的方案等等，不过现在因为硬件越来越强，人工成本反而高，所以。。。现在搞技术的其实越来越幸福越来越容易了

补充下，要根据业务情况做好模拟测试，别拿着书上的东西生搬硬套，比如说一些数据还被别的业务所使用（查询、修改），这就可能会影响到查询、更新两者的负载比例关系（因为 mysql 查询虽快但更新很慢而且并发多了容易锁死），影响到哪种缓存方案合算，我说这些就是说没有绝对的办法，各因素要通盘考虑，但大原则都是要稳妥的设计原始数据存放方案，尽量确保业务需求的修改变动只需要修改缓存方案即可解决。

json 字符串存商品 id list,但是商品没了就不能删除只能标记下架。

表 1 是 sql 的思路
表 2 是 nosql 的思路（ json 存储，不建议逗号）

表 1 可以查某个用户购买过什么，也可以查某个商品被哪些用户买过
表 2 的思路可以作为在 redis 中的存储格式

另外，楼上说商品没了就不能删除只能下架。。我想说，sku 一旦进入数据库，还能有删除这一说？
学校的数据库课程中，有很多说法真的不适合互联网环境下的应用，包括但不限于各种断言触发器以及很多完整性约束。。。

多用第一种方式。
第二种方式是灾难 - -

尽量第一种，另外第二种可以放 kv 缓存数据库，不需要放到 mysql。

第二种叫灾难？哪有这么严重！订单可以用 NoSQL 或 PGSQL/MySQL 的 json 来存，比直接逗号存储要好，查询一样很方便。

op 现在做的就到点子上了。
和上面说的一样，数据结构不需要二选一，你需要方便统计的，第一种，你需要快取的，第二种。

@konakona

请教大神们，为啥都第二种是灾难呢？上面又不要用逗号，改成 JSON 格式存储，这样吗：
{"id":"4","id":"6"}
那岂不是比用逗号占的空间更多，也没有看出这样比用逗号分割好在哪里？

第二种就是典型的自己吃香喝辣喂别人吃屎

@edison111cry 很多数据库的存储引擎可以处理 json，但是你用逗号法，随着记录的复杂化和数量增加，你的逻辑部分处理速度会越来越慢，而且管理起来也很麻烦。

@edison111cry 因为不好查询数据啊……我给你举 2 个例子，顺序来说：
1. 你现在已知的需求也许就是一个商品属于多个分类。 你用自己认为合适的方法实现了。
2. 卧槽，老板突然发春了！！！！！！！！！！！！！！！！！！！！要改成多商品对多需求，同时要做类似（ http://desktops.pconline.com.cn/）太平洋那种多聚合搜索！怎么办！原来的方式效率太低，只能重写，还要考虑之前的数据如何转换成新数据，并且避免沉郁代码等等。

你就知道了-v-

@edison111cry 我补充一下。
我看到你提到了“空间”。
我得提醒你，注意下目前的格局。
刚开始写程序的几年是在第一种水平上思考。
再写几年就会到达第二种水平。

等你接触到分布式部署或者是分表的时候，你就知道，空间不是问题。

我回头看了一下，你提到可能会产生 100w 条数据。既然如此，一定要换一个方式看待这个问题。你可以分表呀～～～～～～～～～～～～

千万不要为了节省所谓的“空间”，去使用逗号存储的方式。你省了这点空间，却增加了性能负担（ CPU、io、mem ），得不偿失。

我们用电脑也知道，比方说你有 500G 的内容，你可以压缩它（你第二种方法就好似压缩），然后压缩到只占用 200G 空间。看起来美好，你用的时候怎么办？而且一直从压缩里拿东西（整表查询和模糊搜索）对硬盘对损耗很大，本来可以用 3 年对硬盘，功耗导致只能用 1 年就坏了。而多买一块硬盘就好比不压缩，分表。

再说一下。
你如果用第二种方法，如果将来客服那边说“我们加错了 10 个商品到 A、B、C 这 3 个分类下，你能帮忙改正到 D 分类下吗”。你写 sql 都要几分钟。如果是用第一种方法存储的，你只需要不到 1 分钟。
本来很简单的事情，反而被处理的复杂了。

我刚开始写代码的时候也遇到过你现在的这个问题，我也曾经做过用第二种方法的。只能说甩手项目，就是做完了，不再管的那种。因为接盘侠肯定会恨死我。为啥？因为本来很块就能处理的问题，变得复杂、难追寻、难处理。

因为我们写代码，要注意低耦合。

第一种 查询起来肯定是毫秒级

@edison111cry 不是存 json，而是有种字段类型叫 json，另外说一下，用 jsonb 会比 json 好。

数据局范式

居然会有人认为第二种好，太可怕了。
如果是想要快速根据用户 id 来取数据，应该加索引。
或者在上一层加缓存。
但第二种无论怎么样都不该出现在关系型数据库的设计里面。

非关系型的觉得第二种未尝不可，但是建议再分列