一个没做过归档需求的产品跟开发battle了起来

某个晚上七点，在下班的地铁上，一群友发出了如下的疑问：

“请教个问题，这数据库备份，各种表的删除和备份，这种需求文档也需要产品经理来写？难道不是技术人员的活儿？”

“什么产品功能都没有，就是因为数据库满了，内存可能不够了，要删除一些表，然后备份到别的地方。建议扩内存，开发也不听。我说我写不了，结果技术就让我看他们以前的留言和代码截图，还是英文的，我真的是服了！气炸了好吗！就算要写，也得把前因后果给我讲清楚啊！什么都不说就让我写，我怎么写？”

产品经理是否需要写数据库备份的需求文档，这在群里引发了一场激烈的讨论。

一、群友的看法

1. 不写派

不需要，除非你会技术、如果你懂的话，可以出，不懂就让技术弄；

不需要写，懂也不需要写；

技术会鄙视，不该你写的瞎写；

这种需求为啥还要产品来写，要开发干嘛；

产品的时间和精力都花在这上面，意味着更有价值的事情被搁置了，产品的本职工作也没做。

2. 论事派

这种行为看起来像是甩锅行为，开发在推卸责任。

根据描述，很明显是在给题主制造麻烦。退一步说，产品可以做到这种程度，但前提是对方也要做到这种程度：应该清楚地解释事情的前因后果，不要给截图，也不要给英文。

3. 要写派

B这是关于表数据归集的问题，需要考虑是按月、季度还是年进行归档。这些归档需求都需要产品经理来定义。在确定归档时间后，系统中的所有查询和统计逻辑都必须考虑到这个归档时间。数据归档通常需要拆分一个菜单或入口进行查询，因此查询页面和交互是不同的。

数据归档由技术人员负责，产品提供规则。例如，归档的频率、归档后的数据在哪里可以查询以及如何处理仪表盘的统计等。由于核心问题是 SQL 查询慢，这影响了许多实时逻辑，所以说升级数据库容量不是万能的。

归档的需求不仅需要产品提供良好的支持，而且对多个业务的影响范围可能大可能小。如果由于归档导致产品出现问题，比如查询不到订单等，产品需要进行设计以解决这些反馈。

二、懂点数据库基本概念

进一步探讨写不写数据归档需求这个问题之前，作为产品经理，有必要了解下数据库是什么以及为什么要数据备份归档，什么是磁盘容量、内存大小，不然像上文群友一样以为升级内存就完事了。

1. 数据库、表、数据

数据库就像一个图书馆，图书馆里面有很多个书架（数据表），存储着各种书籍（数据），每本书都有自己的编号（主键），可以通过编号快速找到对应的书籍。

2. 磁盘容量

磁盘容量就像图书馆的大小，可以容纳的书架数量以及书架大小，决定了能容纳多少本书。数据库的磁盘容量决定了它能存储多少数据。

3. 内存大小

内存就像图书馆的工作人员，负责帮助读者快速找到需要的书籍。内存越大，处理读者请求的能力越强，查询速度也越快。

例子：打工马喽

假设某一个人力资源集团有10个下属公司（10个数据库），每个公司分了10个部门（10张数据表），每个部门有10个马喽工位（因此该数据库总磁盘容量100GB），工位上记录着每个马喽的信息，包括姓名、工号、学历、技能等，意味着每个下属公司最多可以同时收纳100个马喽（存储100GB的数据，数据库会从磁盘读取数据，并加载到内存中进行处理）。

该人力集团由于没有建设信息化，所以给每个分公司设置了10块大黑板 10个匹配专工（数据库内存是10GB），让销售人员接待甲方人力需求的咨询和下单的时候用（系统可以使用这10GB内存来快速访问和操作数据库中的数据）。

集团主要的销售方式是电呼，当有甲方需要咨询外包需求时候，销售人员就会让专工根据客户需求去工位查询各个马喽的信息，并且把符合条件的马喽信息记录在大黑板上，以便跟客户进一步沟通。

最终如果某个马喽被外包成交了，最终要去工位修改马喽的外包信息，以免后面的销售判断错误。

所以说如果黑板够大够多，专工数量越多，动作越快，处理速度就会更快。也就是内存足够大，系统可以快速找到并返回所需信息。但如果内存不足，系统可能需要频繁地从磁盘读取数据，导致查询速度变慢。

当集团业务越来越好，招揽的马喽越来越多，但是黑板和专工也不可能无限放大（不符合资本性价比），因此，对马喽的工位和信息进行分类、归档、迁移，让专工可以根据不同的情况，针对性去不同的地方“找马喽”，就可以提高工作速度了。

三、产品归档需求怎么接

1. 不归档的坏处

一般来说，对于单表的数据量，800万（800W）到1000万（1000W）条数据是一个比较合适的范围。数据量太大的话，会有以下影响：

• 性能下降：随着数据量的增加，查询、插入、更新和删除操作的性能可能会受到影响。大量的数据可能导致数据库的响应时间变慢，尤其是在执行复杂查询或涉及大量数据的操作时。
• 存储和内存需求加大：大量的数据需要更多的存储空间和内存来存储和处理。这可能对硬件资源造成压力，并可能导致存储成本的增加。
• 数据管理和维护困难：处理大量的数据可能会使数据管理、备份和恢复变得更加复杂和耗时。
• 索引和查询优化困难：对于大型数据表，索引的维护和查询优化可能变得更具挑战性，需要更多的关注和优化工作。

最直接的表象，就是用户在做各种查询、统计、导出操作的时候，会巨慢、奇卡无比，甚至会操作失败。

2. 归档需求怎么做提

站在产品经理角度，归档先分两种情况。

1）历史功能或是自身不熟悉的功能

像上文那种情况，针对历史功能需要进行归档，笔者先站个观点：一个尽职的产品经理还是要把需求接下来，以推动工作的展开。

但是，像这种历史功能，开发不是很配合，又有明显的推诿行为，那就需要跟开发沟通，让开发梳理出对应需要归档的表涉及到哪些依赖关系、有什么接口在调用，整理后书面发出来，然后大家再一起评估下有无遗漏，要注意的点之后，再继续推进。

因为归档数据对业务影响可大可小，在不熟悉的情况下千万别贸然推进，搞不好成为背锅对象。

2）新功能需求或自身很熟悉的功能

自己很熟悉的功能，或者是规划新需求，可以先自行梳理后，再跟开发、测试、业务等人员多视角一起评估。

确定分表策略：产品经理确定好数据库分表的策略，包括分表的依据字段、分表的规则，是按时间来归档，还是按某个数据状态来分表。初步拟定后需要与技术团队一起沟通评估。

分表分析沟通：产品经理需要和技术团队对数据库分表的影响进行充分的分析，并与相关利益相关者进行沟通和确认，以确保分表的过程对系统的影响可控。

输出分表需求：分表之后，归档的数据是否允许前端查看，如果需要查看，是分多个菜单，还是在原来的菜单，筛选条件是否针对性进行限制，比如只能按月筛选查看数据，或者按某个状态筛选查看筛选数据。并罗列清楚对应的修改点、修改功能有哪些，需要怎么修改，怎么取数等。

通过合理的数据分表归档策略，能够更好地管理和利用数据，提高系统的性能和可维护性。期待与各位读者共同分享和探讨更多关于数据管理的经验和思考。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！