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

其实就是个低配交换机。

3 公里随便什么车都行。
路不好的话，推荐山地或者防刺胎，至少我的光头胎是不敢骑这种路的。
没地方放，或者只能停路边的话，可以考虑折叠车。折起来放公司更衣室也不占多少地方，不然买太好的车很容易丢。

做医疗系统的话，利用好半夜人少这段时间。
用个表记录对应关系，弄个定时器半夜的时候再改。
跟客户说好，因为修改患者对应关系很复杂，尽量不要瞎搞。一旦真的搞错了，那所有修改第二天生效。
只要能该需求那都不是问题。

如果我是 A ，那么有几种情况。
不想费事的话，就弄个代理。抢到了白赚一杯奶茶，抢不到是你运气不好。
想费点事的话，套个 fiddler 啥的，看着它请求要是没成功就一直发。