早上上班路上读了白鳝老师的文章《那些晦涩的国产数据库文档，我总是能看明白的》，其中提到了一个非常重要的文档，就是Oracle官方文档里的Concepts。勾起了我很多回忆，这其中既有DBA的也有产品经理的。为什么说concepts文档重要，我想分别从两个角色的视角来复盘一下，这个在无数DBA心中无可替代的经典文档，到底用来做什么。
上篇，DBA的摆渡者卡戎
在初学Oracle的时候，一定会被它内部庞大且复杂的组件搞得头大。什么是SGA和PGA？Schema到底是不是等同于用户名？表空间和文件可以多对多吗？
在系统学习Oracle之前，我只在大学课堂上学习过SQL，以及在IBM的DB2团队实习。对于数据库的了解也仅限于增删改查，其他的东西都了解很少。所以在正是学习Oracle的时候，一个巨大的门槛就是庞大的体系以及海量陌生的概念。甚至有些概念，和课堂上老师讲的是有所出入的。怎么样确保自己在学习Oracle的过程中，对每个概念都有迹可循，并且在出现认知冲突的时候找到最权威的参考，成为了每一位初学Oracle的人都要面对的问题。
通过阅读concepts文档，将容易混淆的概念澄清，一步一步让新手了解从物理层面到逻辑抽象层面的对应关系，为后面的学习继续打下基础。也多亏了当时的老师，引荐给我这个文档，才让我在后面的Oracle学习过程中建立起了完整的概念框架。无论后面遇到什么样的新知识和新东西，结合concepts的框架去理解，都能事半功倍。
而concepts内容布局来看，有着如下几个非常宝贵的经验：
- 开篇内容。concepts并不急于从一开始就介绍Oracle数据库。而是从关系型数据库的发展历史开始讲起。这一点好处是可以帮助我们将课堂上所学习的和文档找到第一个结合点。从这里出发，过渡到往后的Oracle发展历程，在到达第一个比较复杂的地方——Oracle体系结构，这比起之前我阅读的一些上来就讲体系结构的数据库教材要好太多了。
- 内容引用。Oracle数据库内容太多了，对于新手来说，难免就会出现读了后面忘了前面，或者前部分某些章节穿插着后面才有的概念。在concepts中，我们常会看见那个段落“See Also”，起初我没有留意到它的实际用处，直到后面阅读的章节越多，概念越多，就越发感到它的方便之处。此外，还有对于Oracle其他文档的引用，我想了解哪部分知识，可以从哪些文档去了解，都有详细列表。
- 图文并茂。光是文字描述对于一个个抽象概念是远远不够的。而此时适当的举例子以及配合图片来阐述，就能够生动很多。比如体系结构图，各个模块之间的关系，光是文字描述，尤其是英文的描述，一定会让很多人看的云里雾里。配上一张图，有一种豁然开朗的感觉。
直到今天，对于每一位初学Oracle的朋友，我都会向他们推荐concepts，通读一遍，以后遇事不决都可以作为工具书使用。
在希腊神话里，冥河的摆渡者是卡戎。然而卡戎也会在休息日，载着生者看看冥河，让活着的人一窥究竟。某种意义上，常在河边走的DBA们，就如同神话里的生者，在concepts文档的指引下，看看河对岸。
下篇，产品经理的阿喀琉斯之踵
那么，为什么白鳝老师会读到诸多参差不齐的国产数据库文档，并且绝大部分都没有concepts章节？作为曾经的国产数据库经理，我和一些同行有过交流，也有过自己的切身体会。这一点上，我想阐述几点原因，或者说是我认为的原因。
首先就是认知的问题。国产数据库的产品经理中，不乏优秀的DBA转行。然而不是每个人都系统学习过Oracle，即便系统学习Oracle，也不见得是从concepts文档学习开始。在去年dtcc上，我和两位同行聊过，其中一位听说过concepts文档，但是没有系统读过，另一位是做大数据转型的，干脆没听过。大家的职业经理不同，导致了对concepts文档的认知有了差异。
其次就是自己产品的数据库概念都没固定。如果对比去年的DTC和今年的DTC，大家会发现不少厂商都增加了自己的AI环节。甚至有些产品，同一个名称和他们两三年前宣传的已经相去甚远。概念没有固定，自然没发去写concepts文档。只有这些概念固化了，不再经常受内部或外部影响，才能总结提炼出最精华的东西。这些需要时间的积累，不是一朝一夕之功。
除此之外，不同公司对产品文档的态度也大相径庭。产品文档，尤其是复杂基础软件的产品文档，都是一个高投入的工作。对于产品文档的专员要求很高，不但要有极强的技术语言转述能力，同时还要有优异沟通能力，和研发、测试、产品经理、客户、外部开发者都能沟通。甚至对于数据库要有一定的动手能力，自己需要先把文档里的场景跑通，建立理解。绝不是现在各种bot能替代的。而很多公司连全职的数据库文档工程师都没有，在有限的投入之下，显然没有精力去做这些。
这就导致了，很多的国产数据库厂商，现在缺少把这个文档建立起来的能力。上家公司的时候，我曾经做过规划，自己用1年的时间，把concepts的大纲写好，再与各个组的同事写作，由负责文档的同事用2-3年的时间初步建立一个版本。然而计划赶不上变化，有些东西最终也就成为了泡影。
希腊神话中，英雄阿喀琉斯曾经浸入冥河从而获取了刀枪不入的肉体。然而唯独脚后跟被遗漏，这也成为了他毕生的弱点。这与concepts之于数据库产品经理有着异曲同工之妙。
写到尾声，我又在想，在我的两个指代之中，冥河到底是什么。可以是一次次生产环境不断的血火淬炼，也可以是一遍遍重复操作带来的认知提升。直到有一天，冥河的水覆盖到了DBA与产品经理的全身，我们也就有了自己的刀枪不入之身。
