这个好，不用每次都开 google 了。

请楼主说明下：

1、 公司规范；
2、公司总体福利（加班费、节假日福利、日常福利、年终福利）；
3、公司行政制度（如上班时间、加班情况）；
4、项目背景，项目进度，人员工作内容。

以上 4 点，至少 2 和 4 你得提一提。你去招聘网站上发布招聘都得填呢。没理由到了这里就啥都不提了。

如果质量不好，价格便宜。
当然不买啊。

老铁好多地方都访问不了影响我看效果~~~~~~~~~

你这样整有点贵，不如入一台 5000 的台式机做游戏机，岂不是更快乐？

兄弟，挂牌的特效好卡啊

微单

尽量规避隐私区域吧

按照借车理论，只要没有签署“租借车辆”的协议，那么借车人如果用车闯死了人，车主负主要责任。就是借车人去坐牢，车主负责赔钱。

那么，自动驾驶的车辆与车主签订了什么呢？这份新兴的协议是否受到法律保护？

从这个角度去考虑问题，很快就能得到答案。

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

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

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

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

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

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

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

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

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

你就知道了-v-

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

嗯嗯，都是经验之谈。老司机了！

吃香真是难看。

我还记得我第一份程序员工作，那是很多年前的事情，我是因为一些发展问题，准备去另一家公司上班，所以提出离职。

然后领导希望我能加班完成工作，然后正好遇上节假日，我希望能拿到 3 倍工资，领导脸色那叫一个难看啊……

不过领导还是答应我了，不过之后几天领导都没有给我好脸色。

2333，我不觉得我在趁火打劫。从那以后凡事节假日我都会要求加班费，这是合理的要求呀。

现在在洗牌了。活下来的都是有背景有大牌融资的，小众和草根的基本得死。