Java 8 表示你说得对

学学线性代数？
看描述拿图像的矩阵算一下就行了。

家用的话，固态个人感觉没必要。至少就我自己来说，使用频率和强度没到需要 cache 的级别。
硬盘的话不差钱就红盘或者酷狼，4T 的 800 左右。便宜点的也行，但噪音控制什么的可能会差点。
至于 MTBF ，个人感觉参考一下就行，都是玄学。该坏的它总是要坏，MTBT 再高也不能保证你就不是倒霉的那个。重要数据多做备份才是正道。

已经放弃了。
它这个目标只有几种，每次只改数值。而且只要你每个月都完成，就会越加越离谱。
断更以前连着跟了好几个月。最近的，4 月是锻炼 3520 分钟，5 月 31 次三环，6 月是燃烧 33400 卡路里，7 月是 240 公里。
8 月和 9 月实在太离谱就没盯着练。
10 月又降回 14 次锻炼 106 分钟，11 月是 14 天每天 973 卡路里。

这东西随缘吧，之前跟着做几个月，感觉都想给个破表打工的。
我上班都没这么累。

@ilaipi 64G 确实能用挺久的了，等你想加内存的时候，应该也不在乎那点频率差了。
但是估计到时候 DDR4 的内存就少了，不过现在 DDR5 的太贵。
这就是为什么大家都劝你还不如省点钱隔段时间换一套甜品，不至于太贵，性能也能跟得上。

@ilaipi 不行。
显卡可以单独换，但 CPU 一般都是和主板芯片组绑定的。你 CPU 和主板换了，内存大概率也要换。
所以你电源买够了，显卡就可以随意换。
然后板 U 套装加内存，甜品级的基本在 3000 以内就能控制住。到时候换就行。

你可以去看看 CPU 天梯图，10 年前的顶配 i7 都打不过现在的 i3
你在用到一半估计就想换机器了。
还不如剩下的钱隔几年换个当时主流配置，机箱电源买够了就行。

@wasd6267016 如果你的主板支持，并且软件有大量 IO 操作，那体验还是有很大区别的。
否则你就算换个 SATA 的也没啥感觉。
不过它家的 0E 没彻底解决前，还不如直接买个国产，还能便宜点。

如果你真的弄了特别多光驱，先确定你电源能不能带的动吧。
然后再看看你主板的说明书，特别是南桥。一般来说 SATA 都是独立的，不会互相影响。
最后再去看你的程序是不是有问题。

随便养点鸡，然后卖 V 友土鸡蛋。
https://www.v2ex.com/t/890560

@gaodq 隐私不好弄。
足够方便老人使用的话，就要内网穿透+易用的 App 。这两点你上国产 NAS 那隐私性就跟网盘差不多了。
自己弄 NAS ，或者群晖+自己做穿透，对于老人来说并不是特别好用。

@optional 都是会被收买的啊。
就算数据不是自己编的，也可以通过选择样本等等手段控制结果。健身补剂那种都已经成重灾区了。
所以就算论文也不能全信，只是个参考而已。
但相对于这个问题而言，可信度还是比“我妈觉得对”高很多的。
毕竟你要养到能赚钱的规模，那种数量不做疾病控制，不用饲料几乎是不可能的。
不为了赚钱的话，住在城市里又毫无关系的话怎么可能买得到。

@cat9life 区别并不大，散养的没准抗生素更多一些。
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9079708/
这是 2020 年的研究，散养（或者说号称散养，他们是直接农贸市场买的“free-range”）的鸡蛋，抗生素检出率并没有什么显著区别，但残留量更高一些。
只能说要是想去市场上买这种“土鸡蛋”，大概率是在交智商税而已。

养殖规模大到可以稳定输出赚钱，和不使用饲料全靠天意随便养养本来就是互斥条件。
现代农业能养活这么多人的基础就是化肥农药和育种，你要想真的完全无科技只能去动物园找野鸡。
还是吃的太多了。

@wxf666

你说闭包表体积大，但实际上当你用来存节点的表有几十上百列，数据量也有几百万的时候，闭包表那点大小相对于邻接表区别就不是很大了。
而且当检索的深度不可预测时，可以一次性获取所有节点就远比需要递归的查询有用的多。

学习这些不同数据模型的时候，应该关注的是他们更加“抽象”意义上的区别，而不是这些实现细节。纠结这些细节意义并不大。
它们提供的是一种解决问题的方法和思路。真正在实际情况中，并不是非一即二的选择。比如你可以同时使用闭包表和邻接表，用邻接表的列去执行相邻节点查询，用闭包表去查所有子节点。如果闭包表可以很大程度上优化你的查询性能，那点多余空间根本无所谓。

就这两种模型来说，应该学到的大概就是。
- 当你只关注某个节点的父子结点，或者有限的几个相邻结点时，那么只保存邻接关系就够了。
- 如果你需要关注某个节点的所有父节点或者子节点，那么最好保存完整的“传递闭包”
只是两种思路而已。
如果你不需要父节点方向的查找，那就不用保存父节点关系。甚至闭包表你也可以不用保存完整的“传递闭包”，用不着的话，指向自身的关系可以不用存。

另外你说的查询次数，你可以 Explain 一下看看数据库是怎么给你优化查询的，你就明白它俩有啥区别了。

@wxf666
数据量大，但是每个分支深度差的比较多，每次检索的时候只找某条记录的子树这类的操作，闭包表就比较合适。
但实际上如果真的有很多需要查询路径，路径权重一类的操作，不如直接上图数据库了。

> 好像一直纠结我如何存储那 5 级表的
算不上纠结，只是觉得没必要。如果我做这个需求，直接一个表。
省全名 /市全名 /区全名 /街全名 /村全名
五个列上全建索引，你那三个需求都可以命中索引的。

这些技术都只是在现有 RDBMS 框架下的优化手段，知道有这个东西就可以了。练习的时候也没必要太过较真这些细节，知道怎么实现就行，真正项目里还得看需求。

@wxf666
> 为嘛网上关于『闭包表』的文章，都不谈这些必要的索引呢？他们用了后，都没性能问题嘛？
一般来说建立索引和优化是数据库基础操作，都不会写在这种文章里。

> 不知如此恐怖的空间换时间方案，相比于其他（如邻接表的）模型，到底能快多少呢？真的值得投入这么多空间来提速吗
所以我早就说了，你这种情况并不适合用闭包表。它是一种通用的设计，但不代表在任何情况下都是最优选择。
而且更重要的，不是说所有“看起来像棵树”的东西都要按照“树的结构”去保存。
你这种情况下，一个表就可以解决问题。你可以打开这个库带的那个 sqlite 文件，里面那个 village 表就足够满足你所有需求了。

@wxf666 大概明白你的问题了。
数据库索引不是只能有一个的，聚类索引只能有一个，但普通索引你可以多加几个。如果一条查询会命中多个索引，那么会用其中选择性最大的。

比如你在祖先节点，后代节点和距离列上都建立单独的索引，这样优化器会自动挑个最大的。或者根据你的查询条件，把它们和距离组合上建立几个联合索引。

你这种情况，（祖先节点，距离）和（后代节点，距离）两个索引就够了。