產品經理是否需要寫數據庫備份的需求文檔？關于這個問題，不同人可能會有不一樣的看法?；蛟S在進一步探討寫不寫數據歸檔需求這個問題之前，產品經理還需要了解下數據庫是什么以及為什么要數據備份歸檔。一起跟著作者來梳理清楚這個問題吧。

某個晚上七點，在下班的地鐵上，一群友發出了如下的疑問：

“請教個問題，這數據庫備份，各種表的刪除和備份，這種需求文檔也需要產品經理來寫？難道不是技術人員的活兒？”

“什么產品功能都沒有，就是因為數據庫滿了，內存可能不夠了，要刪除一些表，然后備份到別的地方。建議擴內存，開發也不聽。我說我寫不了，結果技術就讓我看他們以前的留言和代碼截圖，還是英文的，我真的是服了！氣炸了好嗎！就算要寫，也得把前因后果給我講清楚??！什么都不說就讓我寫，我怎么寫？”

產品經理是否需要寫數據庫備份的需求文檔，這在群里引發了一場激烈的討論。

一、群友的看法

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）新功能需求或自身很熟悉的功能

自己很熟悉的功能，或者是規劃新需求，可以先自行梳理后，再跟開發、測試、業務等人員多視角一起評估。

確定分表策略：產品經理確定好數據庫分表的策略，包括分表的依據字段、分表的規則，是按時間來歸檔，還是按某個數據狀態來分表。初步擬定后需要與技術團隊一起溝通評估。

分表分析溝通：產品經理需要和技術團隊對數據庫分表的影響進行充分的分析，并與相關利益相關者進行溝通和確認，以確保分表的過程對系統的影響可控。

輸出分表需求：分表之后，歸檔的數據是否允許前端查看，如果需要查看，是分多個菜單，還是在原來的菜單，篩選條件是否針對性進行限制，比如只能按月篩選查看數據，或者按某個狀態篩選查看篩選數據。并羅列清楚對應的修改點、修改功能有哪些，需要怎么修改，怎么取數等。

通過合理的數據分表歸檔策略，能夠更好地管理和利用數據，提高系統的性能和可維護性。期待與各位讀者共同分享和探討更多關于數據管理的經驗和思考。