我支持关键不顶用啊。
所有的网站最主要的就是内容。你需要搞定的仅仅是内容提供者，鸡有了 蛋自然慢慢就多了。
现存的几个网站没个是靠观看的普通用户支撑起来的。


而内容咋来？
版权视频： 电影电视剧 你烧钱烧的过腾讯视频、爱奇艺、搜狐、优酷吗？ 动画相关的烧的过 b 站、爱奇艺、a 站、优酷吗？
个人创作者：你靠什么把 b 站、抖音、快手、a 站上的中小创作者吸引到你的环境上？

思考好这些你网站就成了， 腾讯爱奇艺的 ssssssvip 再被骂，有些人该买还是买了。

@winfield 实测还是差不少的，不过国营的不差钱就是大气，无损音乐不开会员一样听。

因为懂得真不多，网上各类文档教材也都是做个小 demo，能从请求到数据库再渲染出页面来就算完了。
从没见过几个真正的完整实现了一个基本网站的小项目。
所以只敢看个热闹，不知道该怎么用这玩意做一个和平时随手搭的 spring 项目功能一致完整项目。

如今我还是这个意思， 互联网应用会收到远超过去的传统行业的项目的并发轰炸。
但数据本身的复杂性和量级则大多不如过去传统企业项目。

因为过去数据结构复杂但机器性能有限，所以出现了数据库三范式，以及使用索引，外键，存储过程各种可以优化查询与执行的方法。

如今对于互联网企业 并发巨大，但机器其实廉价且性能比较富裕，毕竟并发可以通过横向扩展多机分担，而不像当年程序本身在这机器上满载执行就那么慢你能有什么办法。

所以在互联网企业时代，什么狗屁数据库三范式，我数据冗余存多份，每个关联数据里不止存操作人 id，连他的用户名和头像一起存下来，查的时候单查一个表，不比你多表查询快么。再不够就加缓存，当前显示准不准又有什么重要的。

这是我很久之前在另一个外键相关问题里的想法，（说外键影响性能） https://v2ex.com/t/626162

zpf124 166 天前

对于外键影响性能这点我一直持保留态度，如今的传统互联网项目的结构性数据都不一定有 20 年前的银行这类传统大型企业数据量大。
而当年那些企业哪个不用外键？ 如果性能影响真的大，当年计算性能比现在低那么多肯定早就有公司和产品将不用外键推广出来了。


外键对于如今而言最大的缺点其实是灵活性，曾经许多方法和算法为了高性能都用存储过程写到了数据库里，而这些年在互联网企业的示范下我们将这些都挪到了后端代码里，并且从前几年就开始流行将代码再向前挪——GraphQL，因为性能其实没那么吃紧了， 大不了找方法做横向扩展加机器嘛。

而这个时候对于业务层而言，后面那些层就仅仅是提供数据的，只要准确快速即可，业务层自己是就是全功能的，自己来给用户做约束，而不希望后面那些层再额外限制约束业务层影响业务层的功能。
在这种思考方式下，如果他是后端代码实现逻辑的，那么它就不希望数据库来存在存储过程，外键，等在后端代码控制范围外的约束来干扰它。
如果是 GraphQL 的那则是希望连后端代码都别做太多约束限制影响它的查询。

以 java 来说。

1 、(重点原因) 数据库设计的范式、老师讲课的内容，教我们的就是尽量降低时间复杂度和空间复杂度。
int 能存的数据不要用 bigint，vchar(10)够用就不要用 vchar(200)。

因此在设计数据库（我不知道现在还有几家公司是有专门的数据库设计人员参与开发的，反正我见到的都是程序开发自己设计表）的字段时我们的就是使用 int byte char 之类的长度较小的字段存储这类枚举值的，只会在注释里写一下每个枚举对应的解释。 也因此会习惯性的将接口也设计成直接传这个枚举值。
如果传字符串也不是不可以，后端自己 switch case 一下传过来的字符串，将他们转成对应的枚举值就行了，就是要是添加了新值的话，那后端程序每个传这个数据的接口都得更新一遍 switch case，麻烦。

2 、jdk7 才支持 switch （ string ）， 但历史惯性让我们更习惯于使用 int 。
并且在懒得自己做压测、不知道 jdk 对 string 优化到什么程度的情况下，一般的 javaer 会自然的认为 switch case 一个 int 、char 和 enum 的性能是高于字符串的。

@so898 就是我说的那次升级 iOS12 丢数据然后图表生成也卡了。

DailyCost
以前非常好 14 、15 年停更了一阵，后来更新适配 iOS12 之后看按月按年的汇总图表巨卡，后来又更新了几个版本好了一点，但图表统计展示还是不如一开始流畅。

@alect 是给你自己的网站加 https 和 hsts，不是让你给中间人加，你相加也加不上。

还是根据你的话难道是你网站自己加了广告商，结果被运营商给替换了？

如果你只是为了防止运营商中间人给你插广告。那么就像上边说的 https+hsts 。

加了 https 是保证你网站响应的内容是被加密的，中间人截获了无法解密和修改。
加 hsts 会让浏览器在第一次请求的时候直接使用 https，是为了保证 不会出现用户访问到了中间人，然后中间人做代理访问你的 https，这样你网站视角下中间人就是收响应的客户端，防止中间人通过这样的二次倒手修改替换发给实际用户的响应。

看看 外国大佬个人站 https://bellard.org/

让老夫来教教你什么叫极简.jpg

是国内的梅林改版吧？

十有八九是软件中心里 某个的应用挂了或者吃内存导致的。

要么少开那些软件，要么挂个硬盘或者 u 盘，然后搞个虚拟内存增加内存。

所有的奖杯成就系统不都是 游戏自己定义目标和检测目标的么....

晾着，或者回个“？”

他有事自然会接着发，有事说事，不是什么好事或者我不愿意的就找接口搪塞过去。

如果是结婚之类的发请帖的，看以前关系，北漂基本上去不了的，所以以前关系还不错的发个红包说去不了，客气一下；如果以前关系也淡，那就不发红包说去不了，扯两句然后就不回他了。

我们一般是前端改， 因为许多类似这样的接口我们设计的时候都是不传筛选参数代表查询所有。

所以这里一般前端做一个额外处理，选择全部时，不给后端发这个参数。

第一次遇到，发现他全站挂了我都惊了

无符号数和有符号的区间大小是一致的，只是区间范围不一致如, 0~256, -127~128, 如果你这列用不到负数自然用无符号就可以存更多内容。 对性能没啥影响。


整数类型在数据库里设置长度都不会影响到它实际的存储长度。


不过对于实际情况还要看你的代码，以及使用的类库。

我用 java，Mybatis 这种半 ORM 的框架，会写实体类与表对应， 因为 java 没有无符号数字类型一说，这时候在数据库设置无符号反倒是累赘，会产生各种 bug 。
比如默认的自动生成实体类的工具是 byte 对应 tinyint, 而如果设置了无符号，我数据库可以存 200 这个数，而 ORM 查询数据后自动封装生成 bean 的过程就会报 这个值超出了 128 的错误。
再来 还有个属于这个 ORM 自己的特性，如果字段类型设置为 tinyint(1)， 则根据表自动生成实体类的工具会把这个字段对应到 boolean 上。

而且如果家族里的叔伯大爷也只是 M 字脱的话那就不必惊慌，像我爸就那样，最多变成贝吉塔而已形象影响不大。