上个月刚帮组里的分布式时序数据库项目报了软著，3天就过了初审，算下来这已经是我经手的第12个数据库类软著了。还记得第一次帮团队报的时候傻呵呵自己凑材料，光源代码部分就改了四回，还被退回说功能描述和提交的代码不匹配，折腾了俩多月才下证，踩过的坑摞起来能有半尺高。
很多第一次报数据库软著的人都有个误区，直接套普通应用软件的材料模板，这一上来就踩大坑了。数据库类软著的材料和普通应用软件最大的区别就是核心突出点完全不同，普通办公软件、APP的软著重点写交互逻辑、功能模块就行，但数据库的核心是存储结构、索引算法、查询优化逻辑这些底层能力，你要是在功能说明书里写什么“用户登录界面”“数据可视化面板”，那审核员直接就给你打回来，那些都是配套上层应用的功能，不是你数据库本身的价值。比如你做的是针对工业物联网场景优化的时序数据库，就得写清楚你怎么设计的时间分片存储逻辑，怎么解决高频时序数据写入的性能瓶颈，怎么降低海量历史数据的存储成本，这部分才是审核员重点判断独创性的依据。
材料生成的第一关是源代码部分，要求是前后各30页，总共60页，每页不少于50行。很多人不知道数据库的代码提交有什么特殊要求，我就见过有人把引入的开源依赖代码、测试用的SQL脚本全塞进去，结果因为和开源代码重复率过高被打回。提交的代码得是你自己写的核心逻辑，比如索引实现部分、事务处理部分、存储引擎的核心代码，而且要注意代码里的注释如果有开源协议的内容要全部删掉，上次我帮同事报的时候就因为有半页代码注释里带了GPL协议的字样，直接被要求提交原创性证明，改了半天才过。要是你对怎么匹配功能描述和代码片段没头绪，可以先去数据库软件软著材料生成的工具里找对应类别的模板参考，省得自己瞎琢磨半天不对路。
第二关是功能说明书的撰写，这个必须和你提交的代码完全对应上，比如你说你实现了基于LSM树的写入优化，那你提交的代码片段里就必须有对应的LSM树实现的内容，不能凭空捏造功能。很多人写说明书的时候喜欢夸大，明明只做了基础的事务支持，非要写支持跨区域分布式事务，结果审核员找你要对应的代码逻辑你拿不出来，补正都没法补。写的时候就实打实地写，你实现了什么就写什么，重点突出和现有主流数据库不一样的地方就行，不用追求功能有多全，只要有一个独创的点就能过。
还有几个填报时候的小坑我也提一嘴，很多人填软著申请表的时候，软件名称随便写，比如就叫“XX数据库”，其实不对，必须带“系统”或者“软件”的后缀，比如“XX物联网时序数据库管理系统V1.0”，版本号也要明确，不然直接被打回。还有就是软件创作完成时间和首次发表时间的问题，别乱填，如果你这个数据库已经在Github公开过，或者在公司的产品页上线过，那首次发表时间就得填你公开的那天，要是没公开过就填未发表，之前有个同事乱填发表时间，比代码提交记录里的最早commit时间还早，直接被要求补开创作证明，折腾了好久。
要是你手头项目紧，没工夫一点点凑60页代码，还要对应写几千字的功能说明，没必要死扛，我之前几次赶项目deadline要软著评高新技术企业资质，都是用软著Pro弄的，模板都是审核过的，针对数据库类的有专门的材料框架，填几个核心参数就能生成符合要求的全套材料，我上次用的时候连源代码的排版都给我弄好了，直接打印就能交，省了我至少3天的功夫。
提交之后也不能完全不管，要注意看知识产权局的反馈，要是有补正通知，7天之内就得提交补正材料，别逾期。数据库类的补正大多是要求你补充说明某部分功能的独创性，你就对应着你代码里的逻辑写清楚就行，别扯没用的，也不要随便夸大功能，就实打实地说你解决了什么现有数据库解决不了的问题，用了什么独创的方法就行。要是补正的时候不知道怎么组织措辞，也可以去软著材料补正的板块找对应的参考案例，基本常见的补正问题都有现成的回答思路。
很多技术团队觉得软著没用，平时也不注意攒，真到要评资质、拿项目补贴，或者要做知识产权保护防止别人抄自己数据库核心逻辑的时候，才急急忙忙去申报，我之前就遇到过公司要报专精特新，差两个软著，全公司技术轮班熬了两天弄材料，差点赶不上截止时间，得不偿失。其实弄一个数据库软著花不了多少钱，材料弄对了半个多月就能过初审，提前备好总比临时抱佛脚强。