產品經理是否需要寫數據庫備份的需求文件？關於這個問題，不同人可能會有不一樣的看法。或許在進一步探討寫不寫數據歸檔需求這個問題之前，產品經理還需要了解下數據庫是什麽以及為什麽要數據備份歸檔。一起跟著作者來梳理清楚這個問題吧。
某個晚上七點，在下班的地鐵上，一群友發出了如下的疑問：
「請教個問題，這數據庫備份，各種表的刪除和備份，這種需求文件也需要產品經理來寫？難道不是技術人員的活兒？」
「什麽產品功能都沒有，就是因為數據庫滿了，記憶體可能不夠了，要刪除一些表，然後備份到別的地方。建議擴記憶體，開發也不聽。我說我寫不了，結果技術就讓我看他們以前的留言和程式碼截圖，還是英文的，我真的是服了！氣炸了好嗎！就算要寫，也得把前因後果給我講清楚啊！什麽都不說就讓我寫，我怎麽寫？」
產品經理是否需要寫數據庫備份的需求文件 ，這在群裏引發了一場激烈的討論。
一、群友的看法
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）新功能需求或自身很熟悉的功能
自己很熟悉的功能，或者是規劃新需求，可以先自行梳理後，再跟開發、測試、業務等人員多視角一起評估。
確定分表策略：產品經理確定好數據庫分表的策略，包括分表的依據欄位、分表的規則，是按時間來歸檔，還是按某個數據狀態來分表。初步擬定後需要與技術團隊一起溝通評估。
分表分析溝通：產品經理需要和技術團隊對數據庫分表的影響進行充分的分析，並與相關利益相關者進行溝通和確認，以確保分表的過程對系統的影響可控。
輸出分表需求：分表之後，歸檔的數據是否允許前端檢視，如果需要檢視，是分多個選單，還是在原來的選單，篩選條件是否針對性進行限制，比如只能按月篩選檢視數據，或者按某個狀態篩選檢視篩選數據。並羅列清楚對應的修改點、修改功能有哪些，需要怎麽修改，怎麽取數等。
透過合理的數據分表歸檔策略，能夠更好地管理和利用數據，提高系統的效能和可維護性。期待與各位讀者共同分享和探討更多關於數據管理的經驗和思考。
本文由 @別字君 原創釋出於人人都是產品經理。未經作者特許，禁止轉載。
題圖來自Unsplash，基於CC0協定。
該文觀點僅代表作者本人，人人都是產品經理平台僅提供資訊儲存空間服務。
