數據庫對于產品經理來說是一個既熟悉又陌生的概念，雖然產品設計中的數據基本都要與數據庫交互，但平時的工作中也很少接觸到數據庫的具體操作和細節。本文作者通過4個數據庫語句，介紹了數據庫對產品數據增、刪、改、查設計的指導意義，希望能給你帶來幫助。

都說產品經理要懂數據庫，那么今天就通過4個數據庫語句，來講講了解數據庫對產品數據增、刪、改、查設計的指導意義。

數據庫，對于產品經理來說，是一個既熟悉又陌生的概念。熟悉是因為產品設計中的數據基本都需要與數據庫交互，陌生是因為平時工作中很少接觸到數據庫的具體操作和細節。但是，了解一些數據庫的基本知識和常用語句，可以幫助產品經理更好地理解數據的來源和流向，更有效地溝通數據需求和問題，更快速地驗證數據分析的結果。因此，產品經理需要懂得一定的數據庫知識，才能更好地發揮數據在產品設計中的價值。

我們先通過一張圖來簡單了解一下數據庫是什么。

數據庫是一種用于存儲和管理數據的軟件系統。數據庫中的數據通常按照一定的結構組織，形成表（table）和字段（field）。表是數據的集合，字段是數據的屬性。訪問用戶（user）是指可以對數據庫進行操作的人或程序，例如查詢、插入、修改或刪除數據。訪問用戶需要通過數據庫管理系統（DBMS）來連接數據庫，并遵循數據庫的安全規則和權限設置。

了解以上的信息，我們就可以進入正題了。

一、INSERT INTO

INSERT INTO table_name VALUES(value1,value2,value3);

以上是數據庫的插入語句，它表示往指定的數據表中新增一條新數據，它對應的前端操作就是用戶在系統中的“新建”操作，比如便簽應用中新建一條新便簽，或者電商平臺中提交一筆新訂單等。

數據庫插入語句的執行效率受多種因素的影響，其中最主要的有數據量和操作的數據表數量。數據量越大，插入語句需要處理的數據越多，因此執行時間也會越長。操作的數據表數量也會影響插入語句的效率，因為每個數據表都需要進行索引更新、約束檢查等操作，這些操作會消耗系統資源和時間。

因此，產品經理在設計需要收集數據量較多的表單的時候，一般建議做分步填寫保存。例如以下某網站的認證流程。

分步填寫保存的好處是：

• 填寫內容分散，不會讓用戶因為在一個頁面看到需要填寫太多內容而覺得恐慌和焦慮。用戶可以按照自己的節奏和順序，逐步完成所需信息的填寫。
• 如用戶因為網絡問題等被迫中斷填寫，已經填寫的數據會進行保存，不需要用戶重新填寫。用戶可以隨時回到上一步或跳到下一步，繼續之前的操作。
• 將所有的數據分散插入到數據庫，數據量小，提升插入語句的執行效率。數據庫可以更快地處理和存儲用戶的數據，避免出現延遲或錯誤。
• 開發設計時，可以根據業務劃分不同的數據庫表，每步只操作對應的表，減少一次性對多個數據庫表進行操作。這樣可以簡化開發流程，提高代碼質量和可維護性。

二、DELETE

DELETE FROM table_name;

以上是數據庫的刪除語句，它表示從指定的數據表中刪除數據。它對應的前端操作就是用戶在系統中的“刪除”操作。比如刪除便簽、刪除訂單等。

刪除無論對于什么樣的系統，都是一個危險操作，一般刪除后的數據都無法找回，是一個不可逆的操作，因此要求產品經理在設計刪除操作功能時，需要盡可能讓用戶意識到此操作的危險性，引起用戶的關注，關于這塊，有興趣的用戶可以參閱：《誰動了我的文案：一個刪除確認文案，難倒多少產品大漢》。

以上說的是傳統的“硬刪除”操作，后來隨著人們對數據越來越重視，對于在數據庫中刪除數據的行為慎之又慎，因此出現了一種新的操作，叫做“軟刪除”。

軟刪除是一種數據保護技術，它可以使數據在被刪除后仍然保留在數據庫中，但對用戶不可見。軟刪除的好處是可以恢復誤刪的數據，或者進行數據分析和審計。軟刪除的實現方法有多種，例如使用標記字段、使用時間戳、使用單獨的表等。

換句話說，軟刪除是“假刪除”，并不是真正意義上的刪除數據，而是將要刪除的數據標記為“已刪除”的狀態，在前端查詢的時候，這些數據不會被查出來，從用戶的角度來看，這條數據就是已經刪除掉了。

軟刪除有以下好處：

• 可以恢復誤刪的數據，提高數據安全性。
• 可以保留數據的歷史記錄，便于分析和審計。
• 可以避免數據完全刪除后造成的外鍵約束或級聯刪除問題。

同時也有以下弊端：

• 占用額外的存儲空間，可能影響數據庫性能。
• 增加查詢和更新的復雜度，需要考慮標記字段的條件。
• 可能導致數據不一致或冗余，需要定期清理或歸檔。

因此，產品經理應該根據不同的業務場景來區分哪些數據應該軟刪除，哪些數據可以硬刪除，不應該“一刀切”地全部做成軟刪除或硬刪除的設計。

三、UPDATE

UPDATE table_name SET column1=value1,column2=value2;

以上是數據庫的更新語句，它表示將數據表中的目標字段內容修改為指定的內容。它對應的前端操作就是用戶在系統中的“修改”或“更新”操作。比如修改便簽內容，或更新訂單狀態等。

更新語句的執行效率和插入語句一樣，主要受限于更新的數據量和操作的數據表數量，同時也受限于每條語句需要更新的字段數量。因此，產品經理在設計修改功能的時候，建議與“新建”一樣，考慮按照業務或信息屬性分開修改。

如下圖是某平臺個人中心的界面截圖，常規資料、密碼設置、更多資料分別在不同的標簽中填寫和保存，而不是全部放在一個長頁面中進行修改。

下圖是另外一個平臺個人中心的界面截圖，也是相似的設計，不過這個平臺的設計更加激進，是按每個字段分開修改的，這種操作效率比較低，但針對個人資料的修改，倒是無傷大雅，畢竟個人資料這些信息，一旦填寫之后，基本不會修改或很少修改，修改時也只是修改其中的某個信息，但在其他的業務場景下，采用這種設計時需要謹慎，一般建議按業務模塊或信息屬性分類修改，像這種按字段分開修改的設計，只適用于字段較少的場景。

更新語句的執行效率也受單個語句更新的字段數量影響，我們都知道，在進行修改操作的時候，系統都會先將之前的數據讀取出來并讓用戶在此基礎上進行修改并保存。

如下圖，一般情況下，我們在修改信息的時候，哪怕只是改了其中某個字段的某個字，但系統在執行更新語句時，卻需要更新全部字段，這個過程對用戶而言是沒有感知的，而對系統卻是實實在在花費了時間去執行，如果更新的字段足夠多，用戶也會有明顯的感知：明明我只改了一個字，為什么還是需要保存那么長時間？

因此，在某些修改信息的場景下，產品經理也會要求研發工程師先判斷哪些字段是被用戶修改過的，針對沒有修改過的字段，在執行更新語句時，就不更新對應字段的數據。當然，對字段是否被修改進行判斷，也會花費一定的時間，所以，產品經理應事先與研發工程師經過溝通后，再確定具體使用什么樣的方案更合適。

四、SELECT

SELECT * FROM table_name;

以上是數據庫的查詢語句，它表示從指定數據表中查詢所有數據。它對應的前端操作不一定是用戶在系統中進行搜索，比如進入訂單頁面就會看到所有訂單，這個時候雖然用戶沒有進行搜索，但是系統依然需要在數據庫中查詢出訂單數據。

查詢是系統中最常用的操作，我們在系統中看到的所有來自數據庫的數據都是通過查詢得到的。以上提到的3個語句也經常要跟查詢語句一起用，比如注冊賬號時，在往數據庫添加新的賬號信息前，需要先查詢賬號存不存在；修改和刪除數據時，需要先從數據庫中查詢到目標數據，才能夠進行修改和刪除操作。

查詢同樣受限于數據量、查詢的數據表以及查詢的字段數量，產品經理在設計查詢功能時，要求根據業務只查詢必要的字段，而不是動不動就一次性將數據表中所有的字段都查出來。比如我們可以看到很多電商平臺的訂單列表，進入訂單列表的時候，我們并不是看到訂單的所有信息，而是訂單的簡要信息，比如訂單號、金額、產品名稱和封面圖等，當我們點擊訂單之后，才會看到更多的信息，比如地址、物流、付款方式、價格組成、發票、各個節點的時間等。

另一方面，產品經理設計查詢功能時，應盡可能減少聚合搜索的設計。

如下圖所示某業務平臺的訂單搜索模塊，該平臺通過一個搜索框，就可以對訂單的多個信息進行搜索，在這種情況下，當用戶進行搜索的時候，系統需要同時對多個字段進行查詢，甚至可能要同時對多個數據表進行查詢，這種查詢是非常耗費資源和時間的操作。

設計時，建議采用下圖這種，將每個字段分開，只查詢用戶輸入了內容的條件，并且每個輸入框只針對某個數據表的某個字段進行搜索，比如用戶只輸入了手機號，系統就只需要查詢手機號這個字段，可以有效提升搜索效率，并且減輕服務器的負擔。

當然，這并非說聚合搜索就是不可取的，相反，它對提升用戶的體驗有非常好的效果，所以需要根據場景進行設計。一般建議 B 端的產品盡可能減少聚合搜索；C 端產品，在適當的位置可以采用聚合搜索；而移動端的產品設計，基本上都會優先考慮采用聚合搜索，因為移動端屏幕小，展示一堆的查詢條件對用戶來講體驗非常糟糕，但是，在設計查詢條件時，還是要根據實際的業務場景，盡可能減少聚合搜索的字段數量和數據表數量。

五、WHERE

通過以上4個語句，我們已經把產品數據中的增、刪、改、查都講完了，但以上所講到的內容，還缺少一個關鍵，就是“約束”。

新增數據時沒有約束，就會往數據庫添加相同的數據，如果是在注冊場景下，沒有增加判斷注冊賬號是否存在的約束，那么就會出現相同的賬號；

刪除數據時沒有約束，就會將整個數據表中的所有數據刪除掉；

修改數據時沒有約束，就會將整個數據表中的所有數據都改成相同的值；

查詢數據時沒有約束，會影響數據的查詢速度和查詢時間。

對于數據庫語句而言，這個“約束”，就是“WHERE”，一個語句后面帶上“WHERE”，表示是這個語句執行的約束條件。

比如下方的語句表示刪除 ID = 1 的數據：

DELETE FROM table_name WHERE ID = 1;

如果沒有添加這個約束條件，那么執行刪除語句的時候，就會將整個數據表內的數據刪除掉，可想而知，這個后果是多么嚴重。

因此，產品經理在進行與產品數據交互有關的設計時，一定要在需求文檔中寫清楚約束條件，比如新增數據時，哪些情況下不允許新增。如果沒有這些約束條件，對數據而言，造成的后果，可能是災難性的。

以上便是本文全部內容，感謝閱讀。