@JasonLaw 这是一个很基础的问题。

所有的拆分都应当按照业务来进行拆分，而按照 元数据-数据 这种拆分方式，又能够比较好地符合业务边界。

我们假设一个 Article 表 (article_id: int, creator_id: int, created_at: int, is_private:int , content: TEXT)

那么，如果不拆分会存在什么问题？
- 如果 content 较短，不会有明显的性能问题
- 如果 content 较长，**一部分业务操作的性能会受到影响**

那么，对于 Article 实体，有哪些业务操作呢？
1. 修改文章内容(content)
2. 修改是否是私密文章(is_private)

那么，如果不拆分，2 号业务原本不需要获取庞大的 content，所以 2 号业务的性能就会受到很大的影响。因为 ORM 大多数是对实体整存整取。并且，即使 ORM 不读取 content，数据库的性能也要受损，因为行占用的空间变大了）

所以，这种拆分能够优化 2 号业务的性能，避免取太多不需要的数据。
---

从更加抽象的角度来看，1 号业务是关于“数据”的业务，2 号业务是关于“元数据”的业务。

为什么我开头说，所有拆分要按照业务拆分？举个例子，在一个新的项目中，对于 Article 实体，如果所有的业务操作都要依赖于数据和元数据（这种情况罕见），这个时候，即使数据再大，都不需要进行拆分。

总结一下，拆分有 2 个条件：
1. content 较长
2. 存在其他不依赖于 content，但依赖于其他字段的业务

为什么要按照阿里这样拆分？
1. 阿里的拆分恰好是 元数据-数据 的拆分
2. 元数据-数据 这种拆分方式，恰好能够比较好地符合业务边界。

因为其他字段相当于元数据，TEXT 相当于数据。

单独的一个 idea 就可以了，如果还有用数据库的话，就用 docker 。再加上 gitbash

对于当前：帮他写后端接口的测试（也算帮忙排查他的 bug ）
对于以后：学习 Vanilla JS 、Vue，加强对前端的理解。

刚刚创建项目，就直接 50M+了。.Net 也在这个量级。但这个大小也没什么不妥。

迅雷是现有的软件中处于垄断地位的下载器，用户多，自然下载的快

win10 = 100% - ε

@594duck 其实我的意思是，范式会（轻微）拖累 mongo 的性能。某些情况，如果按照范式，就会设计出 2 张或 3 张表，但 mongo 可嵌套对象、数组，就只会有 1 张表。这种设计会违反第一范式，但是这种设计如果设计的好的话，就可以提升性能（或者说就可以发挥面向聚合的分布式数据库的优势）。
但是这种聚合的设计也有学问在里面。如果没有设计能力，还是应该乖乖按照范式来，和微服务没啥关系。

1. 如果没有性能问题，就只用数据库
2. 如果有性能问题，则用多台机器+中间件来把数据库整改成分布式
3. 如果性能进一步达到瓶颈，这时候才需要使用缓存（ redis ）。就涉及到一个问题：缓存的更新策略

同理，上文中的数据库也可以替换为 mongo，就省去了找中间件的问题。如果按照关系型的设计数据库表的方式（范式）来设计 mongo 的表，关系型+中间件的性能是不比 mongo 副本集差的。

联想今年有点顶，建议别买华为，毕竟技术积累不同

熟悉...搭建

2018 年 mi6x 我买过，挺轻薄的，，不玩游戏绰绰有余（储存得买大一点的）。不知道 2020 是哪一款对应的

之前的 1+貌似还是不错的

lombok 会有问题，所以我又去 idea 官网下了个 2020.1

放在环境变量里面，因为不想让代码储存服务提供商、构建服务提供商知道你的数据库密码。

自动化合并、手动化增强音量、自动化切割