昨天说了把简单留给客户，把复杂留给研发。昨天上午在一个和某数据库厂商的交流中我就把这句话送给了他们。昨天上午做了一场数据库文档的交流，因为我以前写过一篇吐槽国产数据库文档的文章，于是某数据库厂商就和我约了这场交流，为了避免广告输出的嫌疑，厂商的名称我就隐去了。
他们上来就问我，作为一个用了*十年的老DBA，你希望数据库厂商能够提供什么样的文档出来。我并没有直接回答这个问题，而是讲了一些目前数据库厂商文档中存在的一些用起来不方便的问题。有些数据库厂商整个文档体系就是一本用户手册，虽然不怎么厚，大体上而内容看似也挺全的，只不过某个用户要去找某个知识点的时候，往往找起来很麻烦，甚至找不到，哪怕找到了，也是寥寥几句话，根本解不了渴。还有些数据库厂商的文档很丰富，很多本，但是有时候为了找一句建表的完整语法，找了各种手册都没有找到完整的。
实际所有国产数据库厂商的文档都缺一本《完全参考手册》，这本手册就像字典一样，包含了所有的数据库产品特性的最完整的描述。实际上Oracle数据库早期也是没有这份文档的，第一份《Complete Reference》还是一个从Oracle离职后的人写的。后来Oracle收购了这本书的版权，在随后的任何一个Oracle发行版里，都多了一本《Reference》的手册。所有的SQL语句语法，系统统计数据、等待事件、系统表和视图的详细描述，都可以纳入到完全参考手册里。在其他的手册里，只需要介绍用到的语法就可以了，只要是想查找完整的信息的时候，都只需要翻阅完全参考手册就可以了。
有了这本完全参考手册后，数据库厂商就可以按照阅读者的角色来组织相关的手册了。数据库的手册可以做成能够让各种角色的人都可以很方便的阅读的模式。而不需要让DBA在一本程序员参考指南里跳跃式查找自己所需要的表碎片整理的语法;也不需要让开发人员不断跳过看不懂的运维管理指导，去查找一条修改数据库参数的语句。用各种角色最适合阅读的形式组织各种专项手册，可以让用户有更好的使用体验，不过对于文档编制来说，要麻烦不少，因为很多内容可能要重复出现在多本不同的手册中，并且很可能每次出现都不完全相同。
除了完全参考手册外，《架构与原理》也是目前国产数据库厂商文档里比较缺乏的内容，理解某个数据库产品的架构与原理有助于更好的使用这个数据库，并在遇到问题的时候能够找到解决问题的正确方向。如果这本书能够写成《Oracle Concepts》这样就最完美了，只不过很可能我们没办法一下子写得很完美。Oracle也是到了8.0才开始有这本手册的。现在很多国产数据库的文档里有些这方面的章节，只不过写的还比较粗浅，内容覆盖也不够全面。实际上保持现在的深度，能够把内容覆盖全了，就已经十分有价值了。
昨天最后谈到的话题是专题文库和知识库的问题，这个数据库厂商已经准备上线知识库网站，并已经准备好了大量的文档。我建议学习一下SQL SERVER的专题文库，把一些常见案例，常见运维维护方法，巡检方法，诊断方法等整理成最佳实践手册，按照主题整理好发布出来。实际上Oracle的MOS上也有一些这样的主题，Oracle编写了大量的Master Notes，并按照一些主题归类，让用户可以通过Master Notes系统的了解某个知识。类似Oracle和SQL SERVER的经验，实际上我们的数据库厂商去他们的网站看看，就可以学到很多东西了。
对于知识库，我建议必须基于知识图谱，能够做深度搜索，否则随着知识库规模的扩大，就很难找到我们所需要的内容了。从我个人的感觉来看，现在的MOS绝对没有二十年前好用，想找到一个很匹配的知识，需要搜索半天才行。
虽然开头说了不想在文章中做广告，不过最后还是做一个我们自己的小广告。我们正在梳理各种国产、开源数据库的运维知识图谱，我也衷心希望有合作意愿的朋友加入到我们的行列中，大家分享运维经验与运维案例，对于参与合作的朋友，可以免费使用我们的知识库，并可以探讨更丰富的合作模式。
原文标题：我希望数据库厂商提供什么样的文档