记录一些最近在知识管理上的思考和总结，可能是系列文，欢迎大家多多讨论留言
最近发现自己关注的几个有意思的产品形态都在向数据库靠拢，大有殊途同归之势。
Strapi —— 从 CMS 到数据库
Strapi 自称是一个开源的 headless（在本文中你无需知道它的含义） CMS（Content Management System，内容管理系统）。
我们都很熟悉各种新闻、官网类的网站。这些网站往往有好几个栏目，每个栏目下面又有好几篇文章。（虽然现在大家都习惯看公众号了，公众号的逻辑也是一样的。
这些网站的背后都有一个管理后台，用来给运营人员编辑并发布文章。这个管理后台就叫做“内容管理系统”。
传统的 CMS 都把文章编辑作为核心功能。但假如你的网站不是一个新闻类网站，而是一个展示商品的网站，每个商品有自己的图片、类目、价格等信息。这时编辑文章的功能就不适合这个网站了。
虽然你也可以把每个商品当成一篇文章，把商品的信息作为正文输入。但一方面它的界面很不优雅美观，另一方面也失去了类目、价格等的“元信息”，后续无法实现诸如根据价格筛选等功能。
而 Strapi 则更加灵活，它允许你自己创建不同的类型。例如，我们可以创建一个“商品”类，在里面增加标题、图片、类目、价格等各个字段。随后你就可以随意地新增、编辑、删除这些商品了。
相比于主要为新闻、博客网站服务的传统 CMS，Strapi 可以藉此胜任各行各业的需要。
相信大家也都能看得出来，Strapi 之所以能做到这么灵活，是因为它向我们开放了自定义数据库表结构的能力。事实上它的实现也是简单的一个类型对应一张表，增加或修改类型还需要重启服务器。
Airtable —— 从 Excel 到数据库
Airtable 是近几年风头正劲的低代码平台代表产品。用一句话来概括，就是高级版的 Excel。
Excel 是很多人在工作中都会用到的软件，我们可以利用它存储和分析数据。对于复杂的功能，也可以利用公式和宏来实现。
不过 Excel 毕竟只是个电子表格，还是有很多功能力不从心。Excel 的单元格本质只是文本，你无法在里面管理图片、视频等多媒体数据；Excel 使用简单的序号来定位行和列，这使得你在 Excel 中建立的公式和 Sheet 之间的联系关系是十分脆弱的，一旦修改了 Excel 的结构，这些精心设计的公式就会崩坏掉。
在网上也有人一针见血地指出，这样的需求其实已经超过了电子表格的范畴，应该用数据库实现。Office 中确实也已有了 Access 数据库。但传统的数据库主要还是藏在软件的后端，对单独使用并不友好，更不用说给零基础的普通用户使用了。
这时就轮到 Airtable 登场了，它把数据库披上了一层 Excel 的外衣，让普通用户也能像操作 Excel 一样简单地操作数据库。用户同样可以通过直接双击单元格录入内容，但表格的每一列不再只是一个 A、B、C 这样的序号，而是有了一个确定的名称和类型。而类型也不再只是单纯的文字，而可以是图片、标签、多选以及与其他表的关联等等。
得到了这些类型信息之后，我们可以做到更多事情。和 Excel 类似的筛选、数据聚类、统计图等功能自不必说，我们还可以把数据表本身以各种不同形式进行展示。例如，你可以把你的照片管理起来，提取其中的图片字段，得到一个画廊；可以输入你的日程安排，得到一本日历；根据你的任务未开始、进行中、已完成等状态，得到一个项目看板。甚至，根据数据表的字段，生成一个表单发给别人填写，代替问卷星的职责。
当然这并不是 Airtable 的全部，基于数据库，他们正在探索更多工作流相关的可能性，不过这和本文就没有太大关系了。也许未来某一天这些功能会变得家喻户晓。
NocoDB —— 从 CRUD 到数据库
NocoDB 在它的 Github 介绍中，第一句话写着 “ Open Source Airtable Alternative ”，意即 Airtable 的开源替代品。由于 Airtable 完全运行在云端，会有不少人考虑到数据安全、隐私、免费、定制化等因素，选择一个开源且可以纯本地运行的替代品使用。
NocoDB 也贴心地提供了预编译的二进制包，供普通用户下载后直接使用，不用了解技术细节。它的功能也和 Airtable（的核心数据库功能）大同小异，此处就不赘述了。
不过如果仅仅是这样，就没必要单独介绍它了。NocoDB 自我介绍的第二句话才真正图穷匕见：“ turns any MySQL, Postgres, SQLite into a Spreadsheet with REST APIs ”。给我任何一个数据库，我可以把它变成一套 REST API，省去了程序员每次都要开发增删改查接口的重复劳动。
事实上，如果你留心一下 NocoDB 的历史，就会发现它最早叫做 Xmysql, which means "One command to generate REST APIs for any MySql database"。也就是说，它最早就是一个单纯为了程序员服务的工具，只是发现了 Airtable 和它们产品形态的相似之处，才更改了名字和描述，以扩展用户群体。
在如今的 NocoDB 中你依然可以找到很多属于程序员的极客部分。例如对 API 的重视：虽然 Airtable 也有完善的 API 功能，不过只是针对少部分用户，并不是重点。而 NocoDB 虽然在其他功能上和 Airtable 还有不小差距，但在 API 上，不仅有 REST API，他们甚至做了 JSSDK，甚至提供了Swagger 生成文档和 Mock 数据。
又比如 NocoDB 允许你在新建列时操控数据库的细节：
不过最绝的还是 NocoDB 允许你在新建项目时连接一个现有的数据库。无论是 Airtable 及其同类产品，还是 Strapi 这些同样的开源产品，都把数据库放在内部维护。而传统的 RoR、Django 等全栈框架又得把数据库和具体的后端技术栈绑定。但 NocoDB 更加灵活，不会侵入你现有的架构之中。
这就使得 NocoDB 非常适合初创公司和个人项目。接入它，你就近乎零成本地获得了一套现成的 API 和管理后台。项目做大之后想要切换技术栈或去掉它，也不会有太大的代价。
Notion —— 从文档到数据库
我应该不用介绍 Notion 了，因为它在这几年实在是太出圈了。
Notion 最早是一个基于块的笔记软件，后续加入了数据库功能（一说是借鉴了 Airtable），从单纯的笔记升级为了知识库，也使它破圈了一波。以至于很多人甚至把数据库当做了 Notion 的核心功能。
Notion 的数据库功能和前面的同类产品大同小异，就不具体介绍了。而 Notion 与其他产品的不同之处在于，它是先有文档，再有数据库的，因此需要考虑如何把数据库和它的文档功能有机地结合在一起。
不像别的数据库应用中，每条记录都只是一条单纯的记录。在 Notion 中数据库的一条记录也是一个页面。你可以把记录展开，然后像普通的页面一样编辑它，插入各种类型的块，与其他页面进行链接。
自 Notion 起，数据库功能几乎成为了所有新一代笔记软件的 must have。为什么会出现这种趋势，这是一个值得思考的问题。传统形式的文档，承载的是我们线性的思考流程。但很多时候我们还需要管理结构化的数据，例如通讯录、日程安排、书单等。数据库才更符合这些场景。有点像是 Strapi 想要解决的问题了。
即使是编辑文档，我们有时仍然希望给文档加上一些额外的元信息。传统文档往往只有一个分类（笔记软件的树形层级可视为多级分类）和多个地位平等的简单标签，无法很好地描述这些额外信息。而解决方法只能是像 Notion 这样把文档也作为数据库的记录来实现。
为什么是数据库？
其实数据库一直都在我们身边，只是从软件开发的幕后走到了普通用户的台前。
各种软件“数据库化”的这一趋势也能体现出软件开发领域的一些思路变化。
在传统的开发流程中，我们需要先确定好一个软件有哪些功能，考虑这些功能如何实现，而去设计一个特定的数据库表结构来满足功能。但用户的需求众口难调，现有的结构和功能往往满足不了所有的需求，开发人员也不得不不断迭代。用户也时常纠结于几个功能大差不差的同类产品之中。
但在一个数据库应用中，我们不再以功能为中心，而是以数据为中心。我们把数据结构的主导权交给了用户，而是去思考从数据出发能做些什么。我们不再单纯服务用户，而是赋能用户。
后者对前者可以说是降维打击。上面这些数据库的应用，可以直接取代掉简单的日程管理、项目管理、问卷等等软件。当然，这也对用户的能力提出了更高的要求。对工具类的开发者来说，也不一定再需要从头构建一个项目，而可以在这类平台的 API 基础上开发更加定制化的功能。
无论是一项技术，还是一门编程语言，它们并非凭空产生，而是反映了它们看待世界的方式。
我们使用数据库，也是对这个现实世界建模。