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

[aliehuhu]

需求：判断用户是否购买过该商品。
表 1 是一个用户买一个商品就加一条记录。

表 2 是一个用户购买的商品都放在一条记录里，用,号隔开，查询的时候读取出这个字段分割成数组再判断。

表 1 的话，如果有一万个用户，一百件商品，最多就会产生 100 万记录了，感觉好多。
该用哪种方法呢？或者有更好的实现方式？

[edison111cry]

@konakona

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

[liprais]

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

[chinvo]

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

[konakona]

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

你就知道了-v-

[konakona]

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

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

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

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

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

[konakona]

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

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

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

[ericls]

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

[des]

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

[ChasYuan]

数据局范式

[robertgenius]

第一种够用，单表不经常删除几千万都没什么压力

[chenxytw]

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

[stcasshern]

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