#职场社畜日常
除了魔幻想不出什么别的词了。
这个时代，S-B 实在太可怜了，一堆人合伙做局骗他们。为什么不想一想，一个没有任何实际价值的行业，它的利润是从哪里来的呢？
如果实在找不到，那你就是利润来源。
https://cdnv2.ruguoapp.com/Fl4HL90M46dVVOuoMfkZJ78Do93wv3.jpg
除了魔幻想不出什么别的词了。
这个时代，S-B 实在太可怜了，一堆人合伙做局骗他们。为什么不想一想，一个没有任何实际价值的行业，它的利润是从哪里来的呢？
如果实在找不到，那你就是利润来源。
https://cdnv2.ruguoapp.com/Fl4HL90M46dVVOuoMfkZJ78Do93wv3.jpg
#职场社畜日常
去年，某里增加了陪伴假和早下班打车，网络上一堆阿里人欢腾鼓舞，随后没多久开始了某里史无前例的大裁员。
今天某动公司也开始放福利了，大家小心吧。
点到为止。
https://cdnv2.ruguoapp.com/FhSmHDYLtbSmVTVv45Jycxi7APQVv3.jpg
去年，某里增加了陪伴假和早下班打车，网络上一堆阿里人欢腾鼓舞，随后没多久开始了某里史无前例的大裁员。
今天某动公司也开始放福利了，大家小心吧。
点到为止。
https://cdnv2.ruguoapp.com/FhSmHDYLtbSmVTVv45Jycxi7APQVv3.jpg
#职场社畜日常
谷歌Google十诫（谷歌十大价值观）
1. 一切以用户为中心,其他一切纷至沓来 Focus on the user and all else will follow.
2. 把一件事做到极致. It’s best to do one thing really, really well.
3. 快比慢好. Fast is better than slow.
4. 网络社会需要民主. Democracy on the web works.
5. 您不一定要在桌子前找答案. You don’t need to be at your desk to need an answer.
6. 不做坏事也能赚钱. You can make money without doing evil.
7. 未知的信息总是存在的. There’s always more information out there.
8. 对信息的需求无所不在. The need for information crosses all borders.
9. 不穿西装也可以严肃认真. You can be serious without a suit.
10. 仅有优秀是远远不够的. Great just isn’t good enough.
谷歌Google十诫（谷歌十大价值观）
1. 一切以用户为中心,其他一切纷至沓来 Focus on the user and all else will follow.
2. 把一件事做到极致. It’s best to do one thing really, really well.
3. 快比慢好. Fast is better than slow.
4. 网络社会需要民主. Democracy on the web works.
5. 您不一定要在桌子前找答案. You don’t need to be at your desk to need an answer.
6. 不做坏事也能赚钱. You can make money without doing evil.
7. 未知的信息总是存在的. There’s always more information out there.
8. 对信息的需求无所不在. The need for information crosses all borders.
9. 不穿西装也可以严肃认真. You can be serious without a suit.
10. 仅有优秀是远远不够的. Great just isn’t good enough.
#职场社畜日常
日常思考：现在高铁已经基本实现一票一座了，为什么大家还会在大厅里有座位的情况下提前40分钟排队？
https://cdnv2.ruguoapp.com/FvaUZxSlAjLosJlJGZkPaTjZ1PtHv3.heic
日常思考：现在高铁已经基本实现一票一座了，为什么大家还会在大厅里有座位的情况下提前40分钟排队？
https://cdnv2.ruguoapp.com/FvaUZxSlAjLosJlJGZkPaTjZ1PtHv3.heic
#职场社畜日常
我想和大家讨论一个东西——
有关实习生在大小（1000人）厂的工作内容，以及面试的时候面试官看重的项目的点。
是不是，大厂接受不来小厂（1000人）的工作模式？
但是我，我的真实想法和真实经历——
我在千人厂待了半年多，每一天都无比充实，每一天都觉得自己有进步。（这可能也是我实习能半年多的原因）
后来我来到了一个大厂（也不算太大，起码业内知名），但是我来了3个月了，我觉得我真的没有一点点的进步。（真的......）我觉得最能够让我成长的事情，就是听组里的大佬们开会讨论一个功能点啥的（但是也没有推进）
所以我就带着这样的简历去秋招了，我会感觉到，对我在大厂的经历，大家貌似更感兴趣，可是明明我在小厂参与的东西更多。
还是说，对于实习生就不会有更高的期待？
但我自己从来不这样定义自己。
没有什么是必须必的，女生就要安稳？文科生就要当hr？实习生就要打杂？
我知道自己的弱点，所以我好像一直比我身边的人会差一点，但是不好意思，我也是你们身边的人了。
我想表达的是，汉密尔顿很小的时候就可以写出很惊心动魄的文章，让自己去大陆学习进修。为什么我是女生就一定要安稳？为什么我是实习生就一定要打杂？
为什么我就不会看不起我的打杂实习？（因为对能力经历没有任何提升啊）
但是我困惑的是，如果大厂对于校招生的期待就是你在大厂打过杂，那么是不是只要我能去大厂实习打杂，我就赢了（起码在校招），那这个校招红利是不是能进行下去到社招或者别的？
到底是平台给你的自信还是你自己给你的自信啊？
所以，看的不是做过什么能做什么，看的是去过哪里镀金呗？
但是，tmd商业社会，核心能力难道不是有能力做事，为企业创造价值吗？
（如果，如果，如果真的核心能力是吃互联网公司的红利，那不好意思，价值观不符合，我来这里，我不为社会带来价值，我就会怀疑我来到这里的意义是个什么？）
但是我看社招的，他们的谈话和工作内容就有意义的多啊，我也想这样啊。
欢迎理性讨论，这个话题困惑我好久啊
https://cdnv2.ruguoapp.com/Fhunvsg2zHOYg8oTOgM2_dnlWgzjv3.jpg
我想和大家讨论一个东西——
有关实习生在大小（1000人）厂的工作内容，以及面试的时候面试官看重的项目的点。
是不是，大厂接受不来小厂（1000人）的工作模式？
但是我，我的真实想法和真实经历——
我在千人厂待了半年多，每一天都无比充实，每一天都觉得自己有进步。（这可能也是我实习能半年多的原因）
后来我来到了一个大厂（也不算太大，起码业内知名），但是我来了3个月了，我觉得我真的没有一点点的进步。（真的......）我觉得最能够让我成长的事情，就是听组里的大佬们开会讨论一个功能点啥的（但是也没有推进）
所以我就带着这样的简历去秋招了，我会感觉到，对我在大厂的经历，大家貌似更感兴趣，可是明明我在小厂参与的东西更多。
还是说，对于实习生就不会有更高的期待？
但我自己从来不这样定义自己。
没有什么是必须必的，女生就要安稳？文科生就要当hr？实习生就要打杂？
我知道自己的弱点，所以我好像一直比我身边的人会差一点，但是不好意思，我也是你们身边的人了。
我想表达的是，汉密尔顿很小的时候就可以写出很惊心动魄的文章，让自己去大陆学习进修。为什么我是女生就一定要安稳？为什么我是实习生就一定要打杂？
为什么我就不会看不起我的打杂实习？（因为对能力经历没有任何提升啊）
但是我困惑的是，如果大厂对于校招生的期待就是你在大厂打过杂，那么是不是只要我能去大厂实习打杂，我就赢了（起码在校招），那这个校招红利是不是能进行下去到社招或者别的？
到底是平台给你的自信还是你自己给你的自信啊？
所以，看的不是做过什么能做什么，看的是去过哪里镀金呗？
但是，tmd商业社会，核心能力难道不是有能力做事，为企业创造价值吗？
（如果，如果，如果真的核心能力是吃互联网公司的红利，那不好意思，价值观不符合，我来这里，我不为社会带来价值，我就会怀疑我来到这里的意义是个什么？）
但是我看社招的，他们的谈话和工作内容就有意义的多啊，我也想这样啊。
欢迎理性讨论，这个话题困惑我好久啊
https://cdnv2.ruguoapp.com/Fhunvsg2zHOYg8oTOgM2_dnlWgzjv3.jpg
👍1
#职场社畜日常
微信也妥协了
以前是1块钱买表情包
现在要10个微信豆
而1块钱只能买7个微信豆
剩下30%被苹果抽水了
https://cdnv2.ruguoapp.com/FisKNYQmmNWWDRD7AImFx1U9OCGOv3.png
微信也妥协了
以前是1块钱买表情包
现在要10个微信豆
而1块钱只能买7个微信豆
剩下30%被苹果抽水了
https://cdnv2.ruguoapp.com/FisKNYQmmNWWDRD7AImFx1U9OCGOv3.png
#职场社畜日常
准备用一篇文章大白话讲透一些大家在工作中遇到的一些技术常识。
比如前端，后端，接口，数据库，页面传参，token。
我们日常生活中肉眼可看到的界面，包括app，网页，小程序，H5等等都属于前端的范畴，可以理解为它们是使用者与后端服务器进行交互的一个工具，通过它来获取和写入数据。
获取数据的过程是怎么样的？
用户点击前端界面的某个按钮后，则前端会触发指令传给到后端，后端接收到前端的指令后，则会从数据库查找数据并加工处理后返回给前端想要的数据，前端拿到数据后，按照指定的样式进行展示。
写入数据的过程是怎么样的？
用户在前端界面输入数据后，则会将数据传给后端，由后端加工处理后将数据写入到数据库的某些表中，最后再将操作结果给到前端，前端对结果进行展示，比如提交成功或失败，给用户一个清晰的指引。
以上只是简要地概括了整个前后端处理数据的流程，让大家快速地对整体流程有个大概的感觉，接下来我再举个具体的例子详细剖析下前后端到底是如何传送，处理及保存数据的
比如数据的写入，我们可以用大家非常熟悉的注册流程来展开讲讲。
首先，注册的第一步，用户需要在注册页面上输入账号和密码，前端会将账号和密码传给后端，这时候，按照上面的说法，后端是不是可以直接把账号和密码写入数据库呢？实际上并不是，上述只是为了方便大家快速理解而简化了处理的过程，实际上后端从前端获取到数据后，还需要做一些逻辑判断:
比如，用户的账号是不是此前已经注册过？如果注册过，这个账号的状态又是怎么样的？是否因为违规被停用过？后端做完一系列的逻辑处理后，也将结果返回给前端，前端接收到结果后，以指定的样式进行展示，这也就是大家在注册的时候，点击登录时所收到的提示。
当然，如果后端判断该账号从来没有存在过，则会将该新账号和密码写入到数据库中，创建出一条新的用户记录。
说到这里，可能就会有人有疑问了，前端好理解，就是一个获取数据的界面，但是后端是什么，跟数据库的关系又是什么呢？
其实，你可以把后端理解为一个数据的加工厂，分别去前端和数据库获取数据进行加工处理，最后给到请求方加工后的结果，后端自己是没有任何数据的，它只有一系列的处理逻辑，所以它必须借助前端获取的或数据库里的数据来辅助它做出合理的判断。
拿上面注册的例子来说，当从前端获取到账号信息后，它还需要跑到数据库中，找到一张专门用于存放用户账号密码信息的表，从这张表中去查找账号的信息，通过两边数据的对比才能得出最终的结论。
为了方便大家加深理解，我再举一个登录的例子，它的处理流程又是怎么样的呢？
首先，用户先打开登录页面，输入用户账号和密码，点击登录后，前端就会将账号和密码传给后端，后端接收到数据后需要做以下的逻辑判断:
该用户账号是否存在？
如果账号存在，密码是不是正确？
如果都正确，让用户成功登录。
如果不正确，则登录不成功。
要判断用户账号是否存在
后端需要拿着前端获取的数据跑到用户表中对比一下看是否存在该账号
如果比对之后发现账号存在，则继续看密码是不是正确。
如果密码也正确，则后端会返回结果给到前端，通知前端这个用户是存在的，前端收到消息后，则让用户成功跳转到首页。
如果后端发现前端传过来的账号或密码跟数据库的根本对不上，则后端同样会将结果返回给到前端，前端收到消息之后，则会触发一条提示，告知用户账号或密码不正确，无法跳转至首页。
所以可见，后端一直都是获取数据，处理数据，最后输出结果的过程，这时候就会引出一个大家在工作中很熟悉的一个名词了，这个名词叫做接口，那到底什么是接口呢？在以上描述的处理过程中，哪些属于接口的内容呢？
大家可以把接口理解成请求方与被请求方互利的一个协议，双方先提前沟通好彼此的需要，我给你什么，你反馈给我什么，确定之后，就按照双方的约定规则落下协议，这就是一个接口，后续我拿着这个协议来找你互换东西，你必须得遵守约定，这就是调用接口的过程。
比如上面注册的例子，前端不需要知道怎么去处理账号信息，只需要把用户账号密码给后端，后端返回给前端具体的注册结果就好了，于是，前端就必须与后端提前约定好，前端应该传给后端什么信息，后端返回给前端什么信息，紧接着，后端就将获取到前端数据后续的一整套处理逻辑，包括与数据库的交互包装成一个接口，定义好接口的地址，后续前端只要按照这个接口的规范进行调用就可以了。
到这里，我们就把前端，后端以及接口基本讲完了，但是，有些人可能又有疑问了，数据库又是什么呢，上面并没有对数据库进行详细说明，大家对它的认知也还停留在它是一个存放数据的地方，当然，还有人可能会说，数据库是研发的事情吧，产品经理或者其他业务岗好像并不需要了解太多吧。
实际上，了解数据库的原理对于做业务的人来说是很有好处的，能够帮助我们更好地跟研发人员沟通，准确地表达自己的诉求，还能对产品的整体架构有更深层次的了解。
比如功能的某个改动点会涉及到底层多大的改动，做好工作量的预估，比如增加某个功能要考虑底层库表的结构是怎么样的，跟研发讨论如何做好延展性等等。
那么，数据库到底是什么呢？
其实说起来也没那么复杂，数据库其实就是一张张的表格，类似excel表，有字段有数值，比如，上面所说的用户账号和密码会存放在一张专门存放用户信息的表中，这张表可能不仅有用户的账号和密码，还会包含用户的姓名，年龄等等，想要获取用户信息都需要到这个表来取。
另外比如电商网站，还会有订单信息，则它们会存放在一张专门用于记录订单信息的表中，比如订单生成时间，订单金额，订单的交易人等等，其他的还有专门存放商品信息的商品表，专门存放卖家信息的卖家表等等。
通常来说，系统中一个实体的信息就会用一张表来存储，比如上面所说的用户就是一个实体，商品是一个实体，订单是一个实体，卖家也是一个实体，于是就会产生很多很多张表。
而且，它们之间并不是互相孤立的，而是互相关联的，比如订单表里面的每笔订单，都需要知道是哪个用户生成的，于是就需要关联到用户表，商品表里面的每个商品，都需要知道是哪个商家上架的，于是商品表就需要与卖家表进行关联，那么，它们是如何进行关联的呢？
每张表的每条记录都会有一个唯一标识，别的表的记录可以通过这个唯一标识与之关联，后续后端到数据库找数据的时候，就可以通过关联关系找到所有想要的数据，比如查订单表的时候，就可以同步查到生成订单的用户是谁，他们的详细信息是什么。
另外，我们还需要了解，表与表存在的几种关系，其中包括，一对一，一对多，多对多的关系，还是拿电商网站来举例。
一个用户可以对应多笔订单，所以用户表与订单表是一对多的关系，则订单表的每条记录都会记录对应的用户id用于关联用户表。
对于电商网站来说，购物车也是一个实体，于是也会有一张专门存放购物车信息的购物车表，而一个用户只能对应一个购物车，所以用户表和购物车表是一对一的关系，所以可以在用户表记录一个购物车id进行关联，也可以在购物车表记录一个用户id进行关联，后续查询购物车记录的时候就可以知道是哪个用户创建的。
一个卖家可以卖多个商品，一个商品可以被多个卖家卖，所以卖家表与商品表是多对多的关系，对于多对多关系，记录方式就不能跟一对一，一对多关系一样了，总不能在一条记录的后面记录一堆的关联id吧，所以，有一种更好的记录方法，就是做一张中间表，专门用于存放它们之间的关系，每一条记录就是一个关系，这样的记录方式更加友好。
所以，到这里数据库的原理就基本讲完了，总而言之，数据库只负责存储数据，而后端则按照前端的请求，到数据库关联的各个表去取数据进行逻辑处理，返回处理结果给到前端进行展示，只要能这个流程理解清楚，以后跟研发同学沟通基本就不会有太大的障碍。
最后，我再给大家普及一个在工作中经常会听到的一个术语，叫做页面传参，很多人并不是很理解，他们只理解接口传参，知道请求后端的时候要将参数传给后端处理，但是，页面传参又是什么东西？
这种传参方式一般只会存在于页面跳转的场景，一个页面跳转到另外一个页面时，把第一个页面获取到的参数按照一定的格式拼接在第二个页面的链接上，第二个页面加载后即可获取到该参数。
比如，用户在登录页面登录后，也会将用户信息通过链接传给首页，首页则会调用后端接口，通过用户信息获取到对应的数据。
另外，还有一个常见的名词叫做Token，比如有时候我们去问研发为什么app老是要我们登录，他们会跟我说，token失效了，那token是什么呢？我们可以把它理解成后端给到前端一个入门的凭证，类似门禁卡一样的东西，你拿着你的身份证信息去物业记录了你的身份，物业对应给你一个门禁，后面你进小区就不需要老是拿着身份证证明你自己了，只要有门禁就可以进小区，token也是一样的东西，前端拿着用户的信息去后端换回了一个规定了有效期的token在前端缓存着，只要它不失效，就不需要再拿用户信息去请求后端，直接就可以登录。
准备用一篇文章大白话讲透一些大家在工作中遇到的一些技术常识。
比如前端，后端，接口，数据库，页面传参，token。
我们日常生活中肉眼可看到的界面，包括app，网页，小程序，H5等等都属于前端的范畴，可以理解为它们是使用者与后端服务器进行交互的一个工具，通过它来获取和写入数据。
获取数据的过程是怎么样的？
用户点击前端界面的某个按钮后，则前端会触发指令传给到后端，后端接收到前端的指令后，则会从数据库查找数据并加工处理后返回给前端想要的数据，前端拿到数据后，按照指定的样式进行展示。
写入数据的过程是怎么样的？
用户在前端界面输入数据后，则会将数据传给后端，由后端加工处理后将数据写入到数据库的某些表中，最后再将操作结果给到前端，前端对结果进行展示，比如提交成功或失败，给用户一个清晰的指引。
以上只是简要地概括了整个前后端处理数据的流程，让大家快速地对整体流程有个大概的感觉，接下来我再举个具体的例子详细剖析下前后端到底是如何传送，处理及保存数据的
比如数据的写入，我们可以用大家非常熟悉的注册流程来展开讲讲。
首先，注册的第一步，用户需要在注册页面上输入账号和密码，前端会将账号和密码传给后端，这时候，按照上面的说法，后端是不是可以直接把账号和密码写入数据库呢？实际上并不是，上述只是为了方便大家快速理解而简化了处理的过程，实际上后端从前端获取到数据后，还需要做一些逻辑判断:
比如，用户的账号是不是此前已经注册过？如果注册过，这个账号的状态又是怎么样的？是否因为违规被停用过？后端做完一系列的逻辑处理后，也将结果返回给前端，前端接收到结果后，以指定的样式进行展示，这也就是大家在注册的时候，点击登录时所收到的提示。
当然，如果后端判断该账号从来没有存在过，则会将该新账号和密码写入到数据库中，创建出一条新的用户记录。
说到这里，可能就会有人有疑问了，前端好理解，就是一个获取数据的界面，但是后端是什么，跟数据库的关系又是什么呢？
其实，你可以把后端理解为一个数据的加工厂，分别去前端和数据库获取数据进行加工处理，最后给到请求方加工后的结果，后端自己是没有任何数据的，它只有一系列的处理逻辑，所以它必须借助前端获取的或数据库里的数据来辅助它做出合理的判断。
拿上面注册的例子来说，当从前端获取到账号信息后，它还需要跑到数据库中，找到一张专门用于存放用户账号密码信息的表，从这张表中去查找账号的信息，通过两边数据的对比才能得出最终的结论。
为了方便大家加深理解，我再举一个登录的例子，它的处理流程又是怎么样的呢？
首先，用户先打开登录页面，输入用户账号和密码，点击登录后，前端就会将账号和密码传给后端，后端接收到数据后需要做以下的逻辑判断:
该用户账号是否存在？
如果账号存在，密码是不是正确？
如果都正确，让用户成功登录。
如果不正确，则登录不成功。
要判断用户账号是否存在
后端需要拿着前端获取的数据跑到用户表中对比一下看是否存在该账号
如果比对之后发现账号存在，则继续看密码是不是正确。
如果密码也正确，则后端会返回结果给到前端，通知前端这个用户是存在的，前端收到消息后，则让用户成功跳转到首页。
如果后端发现前端传过来的账号或密码跟数据库的根本对不上，则后端同样会将结果返回给到前端，前端收到消息之后，则会触发一条提示，告知用户账号或密码不正确，无法跳转至首页。
所以可见，后端一直都是获取数据，处理数据，最后输出结果的过程，这时候就会引出一个大家在工作中很熟悉的一个名词了，这个名词叫做接口，那到底什么是接口呢？在以上描述的处理过程中，哪些属于接口的内容呢？
大家可以把接口理解成请求方与被请求方互利的一个协议，双方先提前沟通好彼此的需要，我给你什么，你反馈给我什么，确定之后，就按照双方的约定规则落下协议，这就是一个接口，后续我拿着这个协议来找你互换东西，你必须得遵守约定，这就是调用接口的过程。
比如上面注册的例子，前端不需要知道怎么去处理账号信息，只需要把用户账号密码给后端，后端返回给前端具体的注册结果就好了，于是，前端就必须与后端提前约定好，前端应该传给后端什么信息，后端返回给前端什么信息，紧接着，后端就将获取到前端数据后续的一整套处理逻辑，包括与数据库的交互包装成一个接口，定义好接口的地址，后续前端只要按照这个接口的规范进行调用就可以了。
到这里，我们就把前端，后端以及接口基本讲完了，但是，有些人可能又有疑问了，数据库又是什么呢，上面并没有对数据库进行详细说明，大家对它的认知也还停留在它是一个存放数据的地方，当然，还有人可能会说，数据库是研发的事情吧，产品经理或者其他业务岗好像并不需要了解太多吧。
实际上，了解数据库的原理对于做业务的人来说是很有好处的，能够帮助我们更好地跟研发人员沟通，准确地表达自己的诉求，还能对产品的整体架构有更深层次的了解。
比如功能的某个改动点会涉及到底层多大的改动，做好工作量的预估，比如增加某个功能要考虑底层库表的结构是怎么样的，跟研发讨论如何做好延展性等等。
那么，数据库到底是什么呢？
其实说起来也没那么复杂，数据库其实就是一张张的表格，类似excel表，有字段有数值，比如，上面所说的用户账号和密码会存放在一张专门存放用户信息的表中，这张表可能不仅有用户的账号和密码，还会包含用户的姓名，年龄等等，想要获取用户信息都需要到这个表来取。
另外比如电商网站，还会有订单信息，则它们会存放在一张专门用于记录订单信息的表中，比如订单生成时间，订单金额，订单的交易人等等，其他的还有专门存放商品信息的商品表，专门存放卖家信息的卖家表等等。
通常来说，系统中一个实体的信息就会用一张表来存储，比如上面所说的用户就是一个实体，商品是一个实体，订单是一个实体，卖家也是一个实体，于是就会产生很多很多张表。
而且，它们之间并不是互相孤立的，而是互相关联的，比如订单表里面的每笔订单，都需要知道是哪个用户生成的，于是就需要关联到用户表，商品表里面的每个商品，都需要知道是哪个商家上架的，于是商品表就需要与卖家表进行关联，那么，它们是如何进行关联的呢？
每张表的每条记录都会有一个唯一标识，别的表的记录可以通过这个唯一标识与之关联，后续后端到数据库找数据的时候，就可以通过关联关系找到所有想要的数据，比如查订单表的时候，就可以同步查到生成订单的用户是谁，他们的详细信息是什么。
另外，我们还需要了解，表与表存在的几种关系，其中包括，一对一，一对多，多对多的关系，还是拿电商网站来举例。
一个用户可以对应多笔订单，所以用户表与订单表是一对多的关系，则订单表的每条记录都会记录对应的用户id用于关联用户表。
对于电商网站来说，购物车也是一个实体，于是也会有一张专门存放购物车信息的购物车表，而一个用户只能对应一个购物车，所以用户表和购物车表是一对一的关系，所以可以在用户表记录一个购物车id进行关联，也可以在购物车表记录一个用户id进行关联，后续查询购物车记录的时候就可以知道是哪个用户创建的。
一个卖家可以卖多个商品，一个商品可以被多个卖家卖，所以卖家表与商品表是多对多的关系，对于多对多关系，记录方式就不能跟一对一，一对多关系一样了，总不能在一条记录的后面记录一堆的关联id吧，所以，有一种更好的记录方法，就是做一张中间表，专门用于存放它们之间的关系，每一条记录就是一个关系，这样的记录方式更加友好。
所以，到这里数据库的原理就基本讲完了，总而言之，数据库只负责存储数据，而后端则按照前端的请求，到数据库关联的各个表去取数据进行逻辑处理，返回处理结果给到前端进行展示，只要能这个流程理解清楚，以后跟研发同学沟通基本就不会有太大的障碍。
最后，我再给大家普及一个在工作中经常会听到的一个术语，叫做页面传参，很多人并不是很理解，他们只理解接口传参，知道请求后端的时候要将参数传给后端处理，但是，页面传参又是什么东西？
这种传参方式一般只会存在于页面跳转的场景，一个页面跳转到另外一个页面时，把第一个页面获取到的参数按照一定的格式拼接在第二个页面的链接上，第二个页面加载后即可获取到该参数。
比如，用户在登录页面登录后，也会将用户信息通过链接传给首页，首页则会调用后端接口，通过用户信息获取到对应的数据。
另外，还有一个常见的名词叫做Token，比如有时候我们去问研发为什么app老是要我们登录，他们会跟我说，token失效了，那token是什么呢？我们可以把它理解成后端给到前端一个入门的凭证，类似门禁卡一样的东西，你拿着你的身份证信息去物业记录了你的身份，物业对应给你一个门禁，后面你进小区就不需要老是拿着身份证证明你自己了，只要有门禁就可以进小区，token也是一样的东西，前端拿着用户的信息去后端换回了一个规定了有效期的token在前端缓存着，只要它不失效，就不需要再拿用户信息去请求后端，直接就可以登录。
❤1
#职场社畜日常
十年前做产品，灵感随手可得，市场流量分散，生机盎然。大公司初涉移动互联网，产品又丑又难用。现在做产品，灵感都要一寸寸地挤，那种火山爆发式的灵感已难寻踪迹。市场流量垄断，自然死气沉沉。大公司在移动互联网完成了流量、资本和用户垄断，比古典互联网更加封闭固化。市场机会越来越少，人才无用武之地，被大厂尽收麾下，就连产品审美大厂也跟上来了。要像以前那样，在功能和设计上碾压成熟的产品已经不再是容易的事情。在流量的冲刷下，即使偶尔有这样的优势已会很快被淹没，难以自发生长。最好结局不过被收编，刀枪入库，束之高阁，软禁死亡。每次我打开 App Store 就不断叹气，除了更新，几乎没什么新 app 可下。
十年前做产品，灵感随手可得，市场流量分散，生机盎然。大公司初涉移动互联网，产品又丑又难用。现在做产品，灵感都要一寸寸地挤，那种火山爆发式的灵感已难寻踪迹。市场流量垄断，自然死气沉沉。大公司在移动互联网完成了流量、资本和用户垄断，比古典互联网更加封闭固化。市场机会越来越少，人才无用武之地，被大厂尽收麾下，就连产品审美大厂也跟上来了。要像以前那样，在功能和设计上碾压成熟的产品已经不再是容易的事情。在流量的冲刷下，即使偶尔有这样的优势已会很快被淹没，难以自发生长。最好结局不过被收编，刀枪入库，束之高阁，软禁死亡。每次我打开 App Store 就不断叹气，除了更新，几乎没什么新 app 可下。
#职场社畜日常
大学舍友家里是中山的灯饰世家。毕业去中山参加她的婚礼，街上全是灯饰店。
之前做米家生活周边产品时，同事说，在丹阳眼镜是放麻袋里按斤卖。
有亲戚在汕头做内衣，一个镇上全是内衣厂，传了几代。子女继续继承工厂，无忧无虑。
https://cdnv2.ruguoapp.com/FsWwHx8TYDgnmjHGhD7Gh-oIn0O_v3.png
大学舍友家里是中山的灯饰世家。毕业去中山参加她的婚礼，街上全是灯饰店。
之前做米家生活周边产品时，同事说，在丹阳眼镜是放麻袋里按斤卖。
有亲戚在汕头做内衣，一个镇上全是内衣厂，传了几代。子女继续继承工厂，无忧无虑。
https://cdnv2.ruguoapp.com/FsWwHx8TYDgnmjHGhD7Gh-oIn0O_v3.png
