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

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

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

@wxf666

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

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

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

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

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

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

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

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

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

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

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

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

@wxf666
> 但实际上，这 66W 行，获取任何一行的子节点 /父节点，都会大规模扫 66W 行或 390W 行的表。。
这个跟你用什么结构存储没关系，单纯从 66W 行的表里检索一条记录而已，处理好索引就行了，并不会扫全表。
而且你只存村级的 62W 数据就够了，用不着 66W 。

> 只是，这个帖子是讨论『闭包表』的合理性，才举了文中的例子的，不是讨论该用哪种模型存储最好
> 即使是我这个固定 5 层的简单树形结构，『闭包表』都不能很好适应啊？何谈任意深度呢？
你实际上是在一个不适合用“闭包表”来处理的需求中，讨论如何使用“闭包表”。在这种场景下没什么使用闭包表的合理性，它当然不能很好适应了，完全是没必要的额外设计。

就算你用闭包表去存这个信息，也根本不必扫这么多数据。取决于你是怎么建立索引的，你给深度列单独建个索引不就行了。

@wxf666 还是要看你的需求，看看主要用哪些方式检索数据。
比如你这帖子前两个需求，压根用不着数据库。直接硬编码数组进去就行了。
对于第三个需求，你可以直接按村级记录存，每条记录带着完整 path 就可以。这也就是一个非常简单的表。实际上就是路径枚举。因为路径深度固定，你也可以直接把几个级别全弄成列加上索引，这样你的几个需求就都能解决了。

那本书里面提到的有个观点很重要，“不要过度设计”。它举例的几种树形结构优化方案，都是针对于不限制深度的树来说的。在你这个需求里，树的结构实际上是固定的，深度也是固定的。那么直接用邻接表也没什么问题。

之前用过一段时间 K30u ，感觉这系列的拍照效果很差，涂抹感非常严重。
如果你不经常拍照的话就没问题，扫个码什么的还是能用的。

狗东打折也是 30 多一瓶，我一般一次都屯好多。但我不用电动，所以也不知道电动加剃须泡什么感觉。

软化效果不管哪个都差不多，不推荐吉列的主要是它那个味道闻起来非常像杀虫剂，妮维雅的能好一些。

单纯从软化效果来说，不管是啥剃须泡，或者更贵的剃须膏，剃须皂什么的，都差不了太多。最主要的还是热敷，你用热毛巾盖上一会效果比什么东西都好。这些主要是提供一个润滑效果。

你可以仔细看看成分表，按照用量排列的。那一大堆 20 多种成分，主要就是水，气体，乳化剂稳定剂等等，都是为了形成“泡沫”用的。真正可以作用到你皮肤上的也就是润滑，保湿，抑菌和一些维生素而已。你觉得没有刺痛感可能单纯就是因为它润滑效果比较好。

所以这东西单纯找个喜欢的味道就行了，想要更多效果不如看看须后水或者其它什么保湿品。

有本老书，SQL 反模式，你可以找来看看。
里面介绍了很多设计关系型数据库时候遇到的问题和解决办法，其中很多问题你拿到 NoSQL 就不是问题了。
这时候你就知道从哪开始了。

为什么“因为要作为源代码包分发”，就不能在项目文件里加个配置项？
虽说统一 IDE 可以减少一些环境问题，但你有能力解决环境配置，公司又没要求统一 IDE 的话，那用什么都是自己的自由吧。非要说 Rider 的配置项不能加，那 VS 的也别加了呗。配置文件最简化，不影响编译的都删掉就行了。
我们 VS 和 Rider 都有，该加的字典配置也都加上了。顶多也就是 Rider 某些 lint 在 Resharper 里面没有而已，不至于会影响最终编译。

"局域网部署"和“数据长期稳定”是冲突项。你要先定义好什么叫“长期稳定”。

就算你用 NAS ，或者其它什么服务器，都免不了硬盘爆炸，泡水，断电烧了机器等问题。所以 IT 部门让你们上云，这样相对于自建解决方案来说更稳定一些。
至于安全不安全取决于你们团队的水平，技术和意识到位不管是云服务还是本地服务都很安全，意识不到位哪个都不行。没什么经验和意识的话，本地服务并不会比云服务更安全，大概率更加危险。
如果不需要“版本管理”功能，那就不要用 SVN ，Git 这种东西，更用不上什么 Gitlab ，完全没意义。

你可以先找台空闲机器开个共享，试用一段时间看看能不能满足需求，一样可以配置账户权限等东西。如果有一定的技术水平，或者 IT 搞得定，可以试试 TrueNAS 这类软件，配置更容易一些。
直接买 NAS 产品主要是提供一个更易用的配置界面，比如配置用户，网络规则，RAID 等等。实际上应用功能方面跟你自己弄个共享差不多，反正大部分文档预览你们也用不了。先确定对于项目组来说功能够用不够用再说。

担心质保就国行，U 盘解锁换服就是了。也就之前有一次版本升级临时禁用了解锁，不乱升级就没事。
不在乎质保的话随便买个便宜的就行，这玩意一般不容易坏。

每次看见这种卖好几年会员的，给我的第一感觉就是这玩意要跑路了。。。

@paramagnetic 我有 iPad pro 2017 ，那个笔插上去其实非常长，每次充电都怕它碰断了。
而且它这个也不是加个转接器就能解决的。那个转接器只是两边的母口，你还得带根 type c 的线。

@PrinceofInj 有些路口有查。大部分还是狭路相逢勇者胜，就看谁不要命了。
你在人行道上，绿灯往前走，左边右转过来的车都能顶着你膝盖往前蹭。

其实就是个低配交换机。