一般来说，一个知识管理系统可以考虑的方案主要有以下几种：
- 全部数据进数据库，每次需要使用的时候再从数据库中读出，通过软件界面呈现给用户。
- 文件保留在文件系统中，只把与文件一一对应的标签、描述、评星等数据保存在数据库中。
- 不使用数据库，而是生成一个与文件对应的描述文件，在该描述文件中记录对应文件的标签、描述、评星等数据。
第 1 种方案最常见，比如 Evernote, OneNote 等都采用这种方案，这种方案自然有很多优点，但也有一个明显缺点：无法与其他软件合作。比如，如果用 Evernote 来储存图片，就无法用看图软件直接看图，也无法用修图软件直接修图。
第 2 种方案也能偶尔见到，一般懂编程的人自己想写一个软件来管理本地文件，很可能采用这个方案。
我现在就是想做一个本地的 文件管理工具, 具体来说就是文件的标签管理工具。本该采用第 2 种方案，但是我突发奇想，能不能采用最容易被否定的第 3 种方案？
第 3 种方案由于会产生大量小文件，因此被人讨厌。但当我真的去把它做出来的时候，经过试用，发现它也有很多好处啊！
多仓库共存
- 采用第 1 种、第 2 种方案时，通常一台电脑里只能有一个账号（或仓库），但我采用第 3 种方案后，发现多仓库共存变得非常容易。
- 比如，用户可能希望把工作和生活分开，建立各自独立的仓库。
- 也可能希望对一类文件单独建立仓库，比如全部自己拍的照片一个仓库，除此之外的其他文件一个通用仓库。
- 由于现在很多人使用笔记本电脑，硬盘容量有限，于是很可能希望在电脑硬盘里建立一个小仓库，在移动硬盘里建立一个大仓库，定期把小仓库的文件移动到大仓库里。
在不同的仓库之间交流时，不需要导入导出。
- 如果使用 Evernote, 如果你想把一份笔记发给朋友，或者你自己有两个账号，想把其中一个账号的笔记移动到另一个账号里，那就需要先导出笔记，再导入笔记。
- 而采用第 3 种方案就很方便了，直接复制或剪切即可。
- 比如上面“多仓库共存”里所述的最后一种情况，把小仓库的东西移到大仓库里的情况，采用第 3 种方案就非常非常方便，直接移动文件即可。
随意移动文件位置，文件夹随意改名。
- 第 2 种方案有一个缺点，移动文件位置、文件夹改名、文件改名都需要在软件界面里进行，因为它的数据库必须对应文件位置和文件名，一旦移动，就对应不上了。
- 而第 3 种方案，信息都在“描述文件”里，只要移动文件的时候把描述文件一起移动即可，信息与文件位置无关。
- 实际使用中，我发现移动文件位置和文件夹改名是很频繁发生的操作，这导致第 2 种方案很不方便。
局部备份到网盘
- 如果采用第 2 种方案，局部备份到网盘将是一个很麻烦的任务，因为标签等信息都在数据库里，与文件是分离的，如果只上传一部分文件到网盘，文件位置（目录）可能发生变化，数据库就对应不上。
- 而如果采用第 3 种方案，那就非常轻松、简单了，完全不受文件位置（目录）的影响，网盘那边随便建一个文件夹即可，只要连同描述文件一起，就可以心情轻松地上传, 重点：信息全在描述文件里！ 不需要备份数据库，不需要管文件位置。
容易定制，容易扩展
- 我根据上述的理念，写了一堆处理描述文件的脚本程序，但我没有把它们整合为一个大而全的软件。
- 虽然我写了一堆程序，有 GUI 界面，可以对文件添加标签、修改标签，对标签进行一些简单管理。但说做了一个软件却不太准确，因为这套东西甚至没有一个固定的形态。
- 比如我这套东西里面最最核心，最重要的就是那个所谓的“描述文件”，是一个 json 文件，但就连它都是可以随意定制的。
- 准确来说，我是考虑到上面所述很少人采用的第 3 种方案的优点，做了一个尝试和示范，结果发现还蛮好用的。
- 由于这个理念本身非常简单，就是处理 json 文件而已，任何编程语言，最基本的编程知识就能做到，因此如果你也想尝试用第 3 种方案来打造自己的知识管理系统，大可以参考这个办法，用自己熟悉的技术栈来做。
代码: https://github.com/ahui2016/bijibiji-project （水平有限，请多包涵）
Select Language