Scio：导入1个版本

2024-12-30T06:15:43Z

导入1个版本

←上一版本		2024年12月30日 (一) 14:15的版本
（没有差异）

2024年12月26日 (四) 04:39 Scio

2024-12-26T04:39:00Z

新页面

<html><style>
#mw-content-text .横条 {
background-color: #4f6b83;
color: white;
padding: 3px;
width: 100%;
border: none;
text-align: left;
outline: none;
font-size: 15px;
}\</style></html>

== 目录结构 ==
<html><div class="横条" >※ 导读</div></html>

　　拥有数据却无法在需要的时候找到它，那它是文件还是垃圾？

　　<s>组织所拥有的数据非常简单，我每次都设计出近乎于完美的目录结构</s>。组织内容的方式是没有尽头的，我们总能找到更适合自己的方案，也不存在某个标准答案，因为除技术外，它更多受体量及时间的影响，例如：<blockquote>
* “动漫”原只是位于“图文影音”目录中的一份子，而现在它自成顶级目录，因为数据量的计算单位由GB提升至了TB。而没有继续增加收藏的原因并非收集完了所有喜爱的作品，只是剩余作品的综合权重不足以无限制的“侵吞”我有限的硬盘空间。当我用于存储资源的空间从数TiB提升至如今的100TiB，这样的抉择就没断过。
* “网站镜像”原只是一个微不足道的项目，存放于微不足道的目录，直到时间这无形的大手使我收藏的站点不断传来无法访问的噩耗，我失去了阅读曾喜爱文章的机会，它便鱼跃龙门，成为了核心项目；曾经发生了一些事件，我按照我的感受将对应的资源放置于“Ａ”目录，可时间的大手抹去了我的感情，以至于我需要时才发觉我无法回忆它的存放位置。
</blockquote>　　自以为完美结构满足的是当下及可预见未来的需求，时间线被拉长它会失效，我们无法预见到的事发生它亦会失效，我们需要不断的修改结构以适应最新的需求。因此，组织与管理的方式没有尽头，有的只是体量增长后的没必要：当动漫资源单独占据一块16TB硬盘而不参与目录结构设计时，我自不必在意；为能力计的妥协：设计出符合需求的复杂结构并不难，难得是遵循这套标准，相较而言，从便利上让步转而采用传统方案才是优解。

　　不可否认的是，我们的眼光大都近似于梦中制定的精密计划和说出的惊天语录，一旦醒来再回味就会发出“wtf？”的疑惑。我们只能在某种程度上对其规范化使资源更便于处理；通过参阅更多信息延长可预见未来的范围、通过性质分离减少情感对归类的误判；利用简易工具及低技术方案在没有过多压力的情况下提升处理效率。这也正是本文计划做的。

　　足够的样本才能训练出合适的结构。样本太少时，难免很多情况无法顾及到，经过推演出的结果又不一定符合需求，有切实的足够多的样本才是重点。总而言之，设计理念围绕两个关键词展开：'''性质分离'''、'''少结构层次'''<html><div class="横条" >※ 性质分离</div></html>

除了文件类型及题材外，我们要从更深远的视角考虑文件结构的设计。

* 例如备份的角度，区分个人文件、网络收集文件、可复刻的文件，对于独一无二的，我们在备份时应更谨慎，而对于可复刻的，我们应当根据来源及复刻难易度调整备份策略，是记录来源、记录文件名(跑目录树)、还是也需要进行备份。
* 例如重要性的角度，区分自产文件、外部文件、珍稀文件，明确哪些内容是需要我们重点呵护的，并做好性质分离，使它们不过分交叉以至于影响后续备份或整理。
* 例如文件体量的角度、剥离了感性后的角度(或者试着冷却一段时间再进行归类)。

从而抵消现行情绪状态对理性的影响，可以最大程度的避免未来找不到文件时发生“当时我为啥这样设计来着？”的窘状。
<html><div class="横条" >※ 少结构层次</div></html>
简洁高层目录，精简目录深度，追溯一个文件的路径越短越好、同级目录越少越好，越精简越方便定义及维护。

当你是囤积大户时，不要用 <u>''媒体资源''</u> 囊括所有的图文影音，尤其是它们各自能占据一块硬盘以上时，让其各自为战。可以按照类型划分文件，但不要过于细分不熟悉领域，而后看自己经常访问什么，并将之目录层级提升（对于具有时效性的，建议软链接/符号链接）。

这一行为的根本是避免维护目录嵌套及设计逻辑带来的额外记忆负担，你设计的越复杂，需要记忆的内容就越多，你注定无法每天都与之打交道，随着时间的推移总有被遗漏的那天，一旦发生便是灾难，你将对你设计的目录感到陌生，就像你曾满腔热血的为标签设计受控词汇表但最终一切归于混乱一样。长时间不用记忆力会衰退，陌生的感觉可以摧毁此前消耗的所有心血，当然更可能的是在这个过程中你发现其实你只频繁使用某个或某几个文件夹，而其他大多数内容都陷入了沉寂路过都不带看一眼的。

打倒复杂设计，让需求主导结构。<html><div class="横条" >※ 综述</div></html>
禀着以上两种理念就能构建出完美方案了吗？不能，未来是不可预见的，我们只能不断的改进以适合未来自己的需求，我们能做的只有尽量做好性质分离和结构层次的把控，从而减少情绪化对客观性影响。

时间能改变结构权重，当下或许我侧重于web档案，因此它是顶级结构，但如果未来我倾向于收集电影呢？电影将由二三级升为顶级结构，这是很好理解的，但难以理解与预见的是随着时间的推移，整个系统近乎于重构的改动。但那是未来的我需要面对的问题，皆是我应该为拥有更大体量的收藏库感到荣幸。

总而言之，这是我的部分目录设计参考：

* 核心文件（现行自产文件）
* 站点存档
* 资料存档
* ……

　

== 文件注释 ==
<sup>''主要针对于来自网络中的文件。''</sup><html><div class="横条" >※ .info</div></html>对于数据收藏癖而言，绝大多数文件都來自于网络，但不是所有内容都來自于标准渠道。
{| class="wikitable"
!
!标准渠道
!非标准渠道
|-
!一般文件
|无需注释
|需要注释
|-
!非标准文件
|视情况而定
|需要注释
|}

* 标准渠道：正规流媒体平台(tidla/qobuz/youtube)或命名严谨的发布组(bt/pt)、打包或分发采取统一结构的组织。
* 非标准渠道：不具备通用性，没有明确的结构，需要记录否则便无法轻易找到文件源头(含同质量替代品)的。
* 一般文件：例如出版媒体等具有规范定义的。
* 非标准文件：个人组织或分发的内容，不具备通用性，没有明确的渠道可以追溯；对一般文件进行了修改导致丢失从标准渠道追溯文件的信息时(包括自己修改文件名)。

这是大概的思路，简单来说，便是一眼知道来源能快速复制同样的文件或上位替代品的，便没必要注释来源，反之则顺手记录（确实没有来源的，例如自制或自己用工具下载的除外）。

我不以标签的形式注释，而是粗暴的在对应目录内添加一个文本文件：<code>.info</code> 用于记录关于该文件的信息，如果要用于记录来源则拓展命名为：<code>.info src</code> 。

注释文本不知可以用于记录来源，更主要的是记录有关文件的信息，它是干什么的、什么时候下载的、需要补充哪些内容。

您可以根据需要自行拓展命名包括但不限于<code>up</code>表示这是持续更新项目、<code>xxx</code>表示来自某个经常出现的数据源……<html><div class="横条" >※ 数据表</div></html>但我个人只使用<code>.info</code>、<code>.info src</code>两种形式，因为我始终遵循精简原则而不节外生枝使系统变得臃肿。

对于文件类型和更新时间，我可以用目录及目录名处理，可以写在.info内，至于我如何知道它是会持续更新的，我只能说依靠记忆，因为我尽管是数据收藏癖，但我很少收集我并不知晓的内容。如果您是随机收集可以考虑用标签文件管理器解决。

对于大型项目，尤其是我自己维护和填充的例如后末日生存文档集、ACG相关（例如BDMV、galgame）我直接在项目文件夹内写统计表，excel、记事本、.md无论什么，只要能达成目的即可。

不论何时，标记只是辅助，我绝对不会让其凌驾于数据之上。

　

== 文件处理 ==
结构变动或处理仍旧有用的文件时请评判行为的三项特征：'''是否可逆，是否可追溯，是否易于寻址'''。并酌情处理（参考[[组织与管理/图文影音#文件结构]]）。
[[Category:组织与管理]]

组织与管理/目录结构 - 版本历史

Scio：​导入1个版本

2024年12月26日 (四) 04:39 Scio

Scio：导入1个版本