产品经理是否需要写数据库备份的需求文档？关于这个问题，不同人可能会有不一样的看法。或许在进一步探讨写不写数据归档需求这个问题之前，产品经理还需要了解下数据库是什么以及为什么要数据备份归档。一起跟着作者来梳理清楚这个问题吧。
某个晚上七点，在下班的地铁上，一群友发出了如下的疑问：
“请教个问题，这数据库备份，各种表的删除和备份，这种需求文档也需要产品经理来写？难道不是技术人员的活儿？”
“什么产品功能都没有，就是因为数据库满了，内存可能不够了，要删除一些表，然后备份到别的地方。建议扩内存，开发也不听。我说我写不了，结果技术就让我看他们以前的留言和代码截图，还是英文的，我真的是服了！气炸了好吗！就算要写，也得把前因后果给我讲清楚啊！什么都不说就让我写，我怎么写？”
产品经理是否需要写数据库备份的需求文档，这在群里引发了一场激烈的讨论。
不需要，除非你会技术、如果你懂的话，可以出，不懂就让技术弄；
不需要写，懂也不需要写；
技术会鄙视，不该你写的瞎写；
这种需求为啥还要产品来写，要开发干嘛；
产品的时间和精力都花在这上面，意味着更有价值的事情被搁置了，产品的本职工作也没做。
这种行为看起来像是甩锅行为，开发在推卸责任。
根据描述，很明显是在给题主制造麻烦。退一步说，产品可以做到这种程度，但前提是对方也要做到这种程度：应该清楚地解释事情的前因后果，不要给截图，也不要给英文。
B这是关于表数据归集的问题，需要考虑是按月、季度还是年进行归档。这些归档需求都需要产品经理来定义。在确定归档时间后，系统中的所有查询和统计逻辑都必须考虑到这个归档时间。数据归档通常需要拆分一个菜单或入口进行查询，因此查询页面和交互是不同的。
数据归档由技术人员负责，产品提供规则。例如，归档的频率、归档后的数据在哪里可以查询以及如何处理仪表盘的统计等。由于核心问题是 SQL 查询慢，这影响了许多实时逻辑，所以说升级数据库容量不是万能的。
归档的需求不仅需要产品提供良好的支持，而且对多个业务的影响范围可能大可能小。如果由于归档导致产品出现问题，比如查询不到订单等，产品需要进行设计以解决这些反馈。
进一步探讨写不写数据归档需求这个问题之前，作为产品经理，有必要了解下数据库是什么以及为什么要数据备份归档，什么是磁盘容量、内存大小，不然像上文群友一样以为升级内存就完事了。
数据库就像一个图书馆，图书馆里面有很多个书架（数据表），存储着各种书籍（数据），每本书都有自己的编号（主键），可以通过编号快速找到对应的书籍。
磁盘容量就像图书馆的大小，可以容纳的书架数量以及书架大小，决定了能容纳多少本书。数据库的磁盘容量决定了它能存储多少数据。
内存就像图书馆的工作人员，负责帮助读者快速找到需要的书籍。内存越大，处理读者请求的能力越强，查询速度也越快。
例子：打工马喽
假设某一个人力资源集团有10个下属公司（10个数据库），每个公司分了10个部门（10张数据表），每个部门有10个马喽工位（因此该数据库总磁盘容量100GB），工位上记录着每个马喽的信息，包括姓名、工号、学历、技能等，意味着每个下属公司最多可以同时收纳100个马喽（存储100GB的数据，数据库会从磁盘读取数据，并加载到内存中进行处理）。
该人力集团由于没有建设信息化，所以给每个分公司设置了10块大黑板+10个匹配专工（数据库内存是10GB），让销售人员接待甲方人力需求的咨询和下单的时候用（系统可以使用这10GB内存来快速访问和操作数据库中的数据）。
集团主要的销售方式是电呼，当有甲方需要咨询外包需求时候，销售人员就会让专工根据客户需求去工位查询各个马喽的信息，并且把符合条件的马喽信息记录在大黑板上，以便跟客户进一步沟通。
最终如果某个马喽被外包成交了，最终要去工位修改马喽的外包信息，以免后面的销售判断错误。
所以说如果黑板够大够多，专工数量越多，动作越快，处理速度就会更快。也就是内存足够大，系统可以快速找到并返回所需信息。但如果内存不足，系统可能需要频繁地从磁盘读取数据，导致查询速度变慢。
当集团业务越来越好，招揽的马喽越来越多，但是黑板和专工也不可能无限放大（不符合资本性价比），因此，对马喽的工位和信息进行分类、归档、迁移，让专工可以根据不同的情况，针对性去不同的地方“找马喽”，就可以提高工作速度了。
一般来说，对于单表的数据量，800万（800W）到1000万（1000W）条数据是一个比较合适的范围。数据量太大的话，会有以下影响：
最直接的表象，就是用户在做各种查询、统计、导出操作的时候，会巨慢、奇卡无比，甚至会操作失败。
站在产品经理角度，归档先分两种情况。
1）历史功能或是自身不熟悉的功能
像上文那种情况，针对历史功能需要进行归档，笔者先站个观点：一个尽职的产品经理还是要把需求接下来，以推动工作的展开。
但是，像这种历史功能，开发不是很配合，又有明显的推诿行为，那就需要跟开发沟通，让开发梳理出对应需要归档的表涉及到哪些依赖关系、有什么接口在调用，整理后书面发出来，然后大家再一起评估下有无遗漏，要注意的点之后，再继续推进。
因为归档数据对业务影响可大可小，在不熟悉的情况下千万别贸然推进，搞不好成为背锅对象。
2）新功能需求或自身很熟悉的功能
自己很熟悉的功能，或者是规划新需求，可以先自行梳理后，再跟开发、测试、业务等人员多视角一起评估。
确定分表策略：产品经理确定好数据库分表的策略，包括分表的依据字段、分表的规则，是按时间来归档，还是按某个数据状态来分表。初步拟定后需要与技术团队一起沟通评估。
分表分析沟通：产品经理需要和技术团队对数据库分表的影响进行充分的分析，并与相关利益相关者进行沟通和确认，以确保分表的过程对系统的影响可控。
输出分表需求：分表之后，归档的数据是否允许前端查看，如果需要查看，是分多个菜单，还是在原来的菜单，筛选条件是否针对性进行限制，比如只能按月筛选查看数据，或者按某个状态筛选查看筛选数据。并罗列清楚对应的修改点、修改功能有哪些，需要怎么修改，怎么取数等。
通过合理的数据分表归档策略，能够更好地管理和利用数据，提高系统的性能和可维护性。期待与各位读者共同分享和探讨更多关于数据管理的经验和思考。
本文由 @别字君 原创发布于人人都是产品经理。未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。