"產品轉技術難度比較大，學習數據表結構就門檻低很多，對產品設計的作用也很明顯。本文會簡單介紹一些產品設計中會用到的數據表結構方面的思考，希望對各位有所幫助。
產品轉技術難度比較大，學習數據表結構就門檻低很多，對產品設計的作用也很明顯。本文會簡單介紹一些產品設計中會用到的數據表結構方面的思考，希望對各位有所幫助。
程序是怎麼運行的呢？
簡單來說，就是去指定的位置（表）取數據，完成運算，放到指定的位置（表）存起來或展示出來。
那麼，怎麼保證取到的/存到的數據是按我們預想的方式來的呢？這就涉及到表結構問題了。
數據表是由表名、表中字段、字段內容組成。本文主要圍繞字段劃分及字段定義兩個部分，介紹在產品設計中需要用到的表結構知識。
一、字段分類
要完成一個流程（運算），我們需要諸多數據（字段），這麼多字段是一張表還是多張表呢？
我們可以以商品上架為例，簡單分析一下。
比方說，倉庫現在還有可口可樂50個，進價2.5元，售價3.5元。
1號貨架只剩5個可樂，小王在19/6/24日15:20:12向該貨架上架20個，預計放在貨架第4層；因為新貨架促銷，打折價3元。
首先，所有相關信息排列：
實際業務會比這個字段更多，全在一張表裡儲存雖然看上去清晰，但是缺點也很明顯——因為將主體相關的屬性、流水、維度等數據全部混在一起，勢必造成大量的數據冗餘。
我們按數據類型拆為屬性表和流水錶。
其中屬性表分為商品SKU和貨架；流水錶為上架操作過程。整理後如下：
"產品轉技術難度比較大，學習數據表結構就門檻低很多，對產品設計的作用也很明顯。本文會簡單介紹一些產品設計中會用到的數據表結構方面的思考，希望對各位有所幫助。
程序是怎麼運行的呢？
簡單來說，就是去指定的位置（表）取數據，完成運算，放到指定的位置（表）存起來或展示出來。
那麼，怎麼保證取到的/存到的數據是按我們預想的方式來的呢？這就涉及到表結構問題了。
數據表是由表名、表中字段、字段內容組成。本文主要圍繞字段劃分及字段定義兩個部分，介紹在產品設計中需要用到的表結構知識。
一、字段分類
要完成一個流程（運算），我們需要諸多數據（字段），這麼多字段是一張表還是多張表呢？
我們可以以商品上架為例，簡單分析一下。
比方說，倉庫現在還有可口可樂50個，進價2.5元，售價3.5元。
1號貨架只剩5個可樂，小王在19/6/24日15:20:12向該貨架上架20個，預計放在貨架第4層；因為新貨架促銷，打折價3元。
首先，所有相關信息排列：
實際業務會比這個字段更多，全在一張表裡儲存雖然看上去清晰，但是缺點也很明顯——因為將主體相關的屬性、流水、維度等數據全部混在一起，勢必造成大量的數據冗餘。
我們按數據類型拆為屬性表和流水錶。
其中屬性表分為商品SKU和貨架；流水錶為上架操作過程。整理後如下：
首先，看一下商品表：
（1）商品屬性（類別，名稱等）跟商品流水（進貨、出貨）混在一起，可以進一步拆分。
（2）“倉庫剩餘個數”，可能進貨的要改、上架的要改、盤點的要改，多個地方都會對這個字段作用。這種情況可以通過實時計算，比寫入覆蓋的方式更為準確。
所以調整後會改為：
注：前臺展示的餘量實時計算，不落表。
可以看到商品流通和之前的上架表非常類似，只相差一個貨架編號。
假設我們把倉庫看做一個大貨架，設為0，兩表合併整理後：
"產品轉技術難度比較大，學習數據表結構就門檻低很多，對產品設計的作用也很明顯。本文會簡單介紹一些產品設計中會用到的數據表結構方面的思考，希望對各位有所幫助。
程序是怎麼運行的呢？
簡單來說，就是去指定的位置（表）取數據，完成運算，放到指定的位置（表）存起來或展示出來。
那麼，怎麼保證取到的/存到的數據是按我們預想的方式來的呢？這就涉及到表結構問題了。
數據表是由表名、表中字段、字段內容組成。本文主要圍繞字段劃分及字段定義兩個部分，介紹在產品設計中需要用到的表結構知識。
一、字段分類
要完成一個流程（運算），我們需要諸多數據（字段），這麼多字段是一張表還是多張表呢？
我們可以以商品上架為例，簡單分析一下。
比方說，倉庫現在還有可口可樂50個，進價2.5元，售價3.5元。
1號貨架只剩5個可樂，小王在19/6/24日15:20:12向該貨架上架20個，預計放在貨架第4層；因為新貨架促銷，打折價3元。
首先，所有相關信息排列：
實際業務會比這個字段更多，全在一張表裡儲存雖然看上去清晰，但是缺點也很明顯——因為將主體相關的屬性、流水、維度等數據全部混在一起，勢必造成大量的數據冗餘。
我們按數據類型拆為屬性表和流水錶。
其中屬性表分為商品SKU和貨架；流水錶為上架操作過程。整理後如下：
首先，看一下商品表：
（1）商品屬性（類別，名稱等）跟商品流水（進貨、出貨）混在一起，可以進一步拆分。
（2）“倉庫剩餘個數”，可能進貨的要改、上架的要改、盤點的要改，多個地方都會對這個字段作用。這種情況可以通過實時計算，比寫入覆蓋的方式更為準確。
所以調整後會改為：
注：前臺展示的餘量實時計算，不落表。
可以看到商品流通和之前的上架表非常類似，只相差一個貨架編號。
假設我們把倉庫看做一個大貨架，設為0，兩表合併整理後：
再來看貨架表，“商品種類數”適用實時計算，不落表。（類似前文倉庫餘量計算）。
還有一個問題非常突出——商品詳情這欄內容特別多。
非結構化數據，不便處理，且與其他表內容重複（比如商品名稱和售價）。同樣的字段最好只在一個地方維護，避免表之間的數據衝突。商品名稱很明顯放在商品屬性裡。
那售價這個字段應該放在商品還是貨架上的商品詳情？
這其實跟業務模式相關，放在商品裡方便全局管理，但是單個貨架不能實現差別化定價；相反，放在貨架上，同一商品在不同貨架上可以設置不同售價，缺點是修改調整比較困難。
根據我們的業務情況，售價主要是統一管理，放在了商品屬性；折扣主要是單個貨架進行，所以折扣價放在了貨架的商品詳情。
調整後如下：
數據結構確認之後，頁面內容設計就比較清晰了：
【商品】
"產品轉技術難度比較大，學習數據表結構就門檻低很多，對產品設計的作用也很明顯。本文會簡單介紹一些產品設計中會用到的數據表結構方面的思考，希望對各位有所幫助。
程序是怎麼運行的呢？
簡單來說，就是去指定的位置（表）取數據，完成運算，放到指定的位置（表）存起來或展示出來。
那麼，怎麼保證取到的/存到的數據是按我們預想的方式來的呢？這就涉及到表結構問題了。
數據表是由表名、表中字段、字段內容組成。本文主要圍繞字段劃分及字段定義兩個部分，介紹在產品設計中需要用到的表結構知識。
一、字段分類
要完成一個流程（運算），我們需要諸多數據（字段），這麼多字段是一張表還是多張表呢？
我們可以以商品上架為例，簡單分析一下。
比方說，倉庫現在還有可口可樂50個，進價2.5元，售價3.5元。
1號貨架只剩5個可樂，小王在19/6/24日15:20:12向該貨架上架20個，預計放在貨架第4層；因為新貨架促銷，打折價3元。
首先，所有相關信息排列：
實際業務會比這個字段更多，全在一張表裡儲存雖然看上去清晰，但是缺點也很明顯——因為將主體相關的屬性、流水、維度等數據全部混在一起，勢必造成大量的數據冗餘。
我們按數據類型拆為屬性表和流水錶。
其中屬性表分為商品SKU和貨架；流水錶為上架操作過程。整理後如下：
首先，看一下商品表：
（1）商品屬性（類別，名稱等）跟商品流水（進貨、出貨）混在一起，可以進一步拆分。
（2）“倉庫剩餘個數”，可能進貨的要改、上架的要改、盤點的要改，多個地方都會對這個字段作用。這種情況可以通過實時計算，比寫入覆蓋的方式更為準確。
所以調整後會改為：
注：前臺展示的餘量實時計算，不落表。
可以看到商品流通和之前的上架表非常類似，只相差一個貨架編號。
假設我們把倉庫看做一個大貨架，設為0，兩表合併整理後：
再來看貨架表，“商品種類數”適用實時計算，不落表。（類似前文倉庫餘量計算）。
還有一個問題非常突出——商品詳情這欄內容特別多。
非結構化數據，不便處理，且與其他表內容重複（比如商品名稱和售價）。同樣的字段最好只在一個地方維護，避免表之間的數據衝突。商品名稱很明顯放在商品屬性裡。
那售價這個字段應該放在商品還是貨架上的商品詳情？
這其實跟業務模式相關，放在商品裡方便全局管理，但是單個貨架不能實現差別化定價；相反，放在貨架上，同一商品在不同貨架上可以設置不同售價，缺點是修改調整比較困難。
根據我們的業務情況，售價主要是統一管理，放在了商品屬性；折扣主要是單個貨架進行，所以折扣價放在了貨架的商品詳情。
調整後如下：
數據結構確認之後，頁面內容設計就比較清晰了：
【商品】
【貨架】
"產品轉技術難度比較大，學習數據表結構就門檻低很多，對產品設計的作用也很明顯。本文會簡單介紹一些產品設計中會用到的數據表結構方面的思考，希望對各位有所幫助。
程序是怎麼運行的呢？
簡單來說，就是去指定的位置（表）取數據，完成運算，放到指定的位置（表）存起來或展示出來。
那麼，怎麼保證取到的/存到的數據是按我們預想的方式來的呢？這就涉及到表結構問題了。
數據表是由表名、表中字段、字段內容組成。本文主要圍繞字段劃分及字段定義兩個部分，介紹在產品設計中需要用到的表結構知識。
一、字段分類
要完成一個流程（運算），我們需要諸多數據（字段），這麼多字段是一張表還是多張表呢？
我們可以以商品上架為例，簡單分析一下。
比方說，倉庫現在還有可口可樂50個，進價2.5元，售價3.5元。
1號貨架只剩5個可樂，小王在19/6/24日15:20:12向該貨架上架20個，預計放在貨架第4層；因為新貨架促銷，打折價3元。
首先，所有相關信息排列：
實際業務會比這個字段更多，全在一張表裡儲存雖然看上去清晰，但是缺點也很明顯——因為將主體相關的屬性、流水、維度等數據全部混在一起，勢必造成大量的數據冗餘。
我們按數據類型拆為屬性表和流水錶。
其中屬性表分為商品SKU和貨架；流水錶為上架操作過程。整理後如下：
首先，看一下商品表：
（1）商品屬性（類別，名稱等）跟商品流水（進貨、出貨）混在一起，可以進一步拆分。
（2）“倉庫剩餘個數”，可能進貨的要改、上架的要改、盤點的要改，多個地方都會對這個字段作用。這種情況可以通過實時計算，比寫入覆蓋的方式更為準確。
所以調整後會改為：
注：前臺展示的餘量實時計算，不落表。
可以看到商品流通和之前的上架表非常類似，只相差一個貨架編號。
假設我們把倉庫看做一個大貨架，設為0，兩表合併整理後：
再來看貨架表，“商品種類數”適用實時計算，不落表。（類似前文倉庫餘量計算）。
還有一個問題非常突出——商品詳情這欄內容特別多。
非結構化數據，不便處理，且與其他表內容重複（比如商品名稱和售價）。同樣的字段最好只在一個地方維護，避免表之間的數據衝突。商品名稱很明顯放在商品屬性裡。
那售價這個字段應該放在商品還是貨架上的商品詳情？
這其實跟業務模式相關，放在商品裡方便全局管理，但是單個貨架不能實現差別化定價；相反，放在貨架上，同一商品在不同貨架上可以設置不同售價，缺點是修改調整比較困難。
根據我們的業務情況，售價主要是統一管理，放在了商品屬性；折扣主要是單個貨架進行，所以折扣價放在了貨架的商品詳情。
調整後如下：
數據結構確認之後，頁面內容設計就比較清晰了：
【商品】
【貨架】
【貨架詳情】
"產品轉技術難度比較大，學習數據表結構就門檻低很多，對產品設計的作用也很明顯。本文會簡單介紹一些產品設計中會用到的數據表結構方面的思考，希望對各位有所幫助。
程序是怎麼運行的呢？
簡單來說，就是去指定的位置（表）取數據，完成運算，放到指定的位置（表）存起來或展示出來。
那麼，怎麼保證取到的/存到的數據是按我們預想的方式來的呢？這就涉及到表結構問題了。
數據表是由表名、表中字段、字段內容組成。本文主要圍繞字段劃分及字段定義兩個部分，介紹在產品設計中需要用到的表結構知識。
一、字段分類
要完成一個流程（運算），我們需要諸多數據（字段），這麼多字段是一張表還是多張表呢？
我們可以以商品上架為例，簡單分析一下。
比方說，倉庫現在還有可口可樂50個，進價2.5元，售價3.5元。
1號貨架只剩5個可樂，小王在19/6/24日15:20:12向該貨架上架20個，預計放在貨架第4層；因為新貨架促銷，打折價3元。
首先，所有相關信息排列：
實際業務會比這個字段更多，全在一張表裡儲存雖然看上去清晰，但是缺點也很明顯——因為將主體相關的屬性、流水、維度等數據全部混在一起，勢必造成大量的數據冗餘。
我們按數據類型拆為屬性表和流水錶。
其中屬性表分為商品SKU和貨架；流水錶為上架操作過程。整理後如下：
首先，看一下商品表：
（1）商品屬性（類別，名稱等）跟商品流水（進貨、出貨）混在一起，可以進一步拆分。
（2）“倉庫剩餘個數”，可能進貨的要改、上架的要改、盤點的要改，多個地方都會對這個字段作用。這種情況可以通過實時計算，比寫入覆蓋的方式更為準確。
所以調整後會改為：
注：前臺展示的餘量實時計算，不落表。
可以看到商品流通和之前的上架表非常類似，只相差一個貨架編號。
假設我們把倉庫看做一個大貨架，設為0，兩表合併整理後：
再來看貨架表，“商品種類數”適用實時計算，不落表。（類似前文倉庫餘量計算）。
還有一個問題非常突出——商品詳情這欄內容特別多。
非結構化數據，不便處理，且與其他表內容重複（比如商品名稱和售價）。同樣的字段最好只在一個地方維護，避免表之間的數據衝突。商品名稱很明顯放在商品屬性裡。
那售價這個字段應該放在商品還是貨架上的商品詳情？
這其實跟業務模式相關，放在商品裡方便全局管理，但是單個貨架不能實現差別化定價；相反，放在貨架上，同一商品在不同貨架上可以設置不同售價，缺點是修改調整比較困難。
根據我們的業務情況，售價主要是統一管理，放在了商品屬性；折扣主要是單個貨架進行，所以折扣價放在了貨架的商品詳情。
調整後如下：
數據結構確認之後，頁面內容設計就比較清晰了：
【商品】
【貨架】
【貨架詳情】
【商品流轉】
"產品轉技術難度比較大，學習數據表結構就門檻低很多，對產品設計的作用也很明顯。本文會簡單介紹一些產品設計中會用到的數據表結構方面的思考，希望對各位有所幫助。
程序是怎麼運行的呢？
簡單來說，就是去指定的位置（表）取數據，完成運算，放到指定的位置（表）存起來或展示出來。
那麼，怎麼保證取到的/存到的數據是按我們預想的方式來的呢？這就涉及到表結構問題了。
數據表是由表名、表中字段、字段內容組成。本文主要圍繞字段劃分及字段定義兩個部分，介紹在產品設計中需要用到的表結構知識。
一、字段分類
要完成一個流程（運算），我們需要諸多數據（字段），這麼多字段是一張表還是多張表呢？
我們可以以商品上架為例，簡單分析一下。
比方說，倉庫現在還有可口可樂50個，進價2.5元，售價3.5元。
1號貨架只剩5個可樂，小王在19/6/24日15:20:12向該貨架上架20個，預計放在貨架第4層；因為新貨架促銷，打折價3元。
首先，所有相關信息排列：
實際業務會比這個字段更多，全在一張表裡儲存雖然看上去清晰，但是缺點也很明顯——因為將主體相關的屬性、流水、維度等數據全部混在一起，勢必造成大量的數據冗餘。
我們按數據類型拆為屬性表和流水錶。
其中屬性表分為商品SKU和貨架；流水錶為上架操作過程。整理後如下：
首先，看一下商品表：
（1）商品屬性（類別，名稱等）跟商品流水（進貨、出貨）混在一起，可以進一步拆分。
（2）“倉庫剩餘個數”，可能進貨的要改、上架的要改、盤點的要改，多個地方都會對這個字段作用。這種情況可以通過實時計算，比寫入覆蓋的方式更為準確。
所以調整後會改為：
注：前臺展示的餘量實時計算，不落表。
可以看到商品流通和之前的上架表非常類似，只相差一個貨架編號。
假設我們把倉庫看做一個大貨架，設為0，兩表合併整理後：
再來看貨架表，“商品種類數”適用實時計算，不落表。（類似前文倉庫餘量計算）。
還有一個問題非常突出——商品詳情這欄內容特別多。
非結構化數據，不便處理，且與其他表內容重複（比如商品名稱和售價）。同樣的字段最好只在一個地方維護，避免表之間的數據衝突。商品名稱很明顯放在商品屬性裡。
那售價這個字段應該放在商品還是貨架上的商品詳情？
這其實跟業務模式相關，放在商品裡方便全局管理，但是單個貨架不能實現差別化定價；相反，放在貨架上，同一商品在不同貨架上可以設置不同售價，缺點是修改調整比較困難。
根據我們的業務情況，售價主要是統一管理，放在了商品屬性；折扣主要是單個貨架進行，所以折扣價放在了貨架的商品詳情。
調整後如下：
數據結構確認之後，頁面內容設計就比較清晰了：
【商品】
【貨架】
【貨架詳情】
【商品流轉】
注：在實際產品中，頁面入口可能帶有一些參數，比如上圖如果是點擊“進貨”按鈕的彈出框，就無需再手動選擇交易類型。
二、字段類型
前面從大的範圍上介紹了字段的劃分，細節上單個字段的類型、長度也需要加以關注。
一些常用的字段類型：
"產品轉技術難度比較大，學習數據表結構就門檻低很多，對產品設計的作用也很明顯。本文會簡單介紹一些產品設計中會用到的數據表結構方面的思考，希望對各位有所幫助。
程序是怎麼運行的呢？
簡單來說，就是去指定的位置（表）取數據，完成運算，放到指定的位置（表）存起來或展示出來。
那麼，怎麼保證取到的/存到的數據是按我們預想的方式來的呢？這就涉及到表結構問題了。
數據表是由表名、表中字段、字段內容組成。本文主要圍繞字段劃分及字段定義兩個部分，介紹在產品設計中需要用到的表結構知識。
一、字段分類
要完成一個流程（運算），我們需要諸多數據（字段），這麼多字段是一張表還是多張表呢？
我們可以以商品上架為例，簡單分析一下。
比方說，倉庫現在還有可口可樂50個，進價2.5元，售價3.5元。
1號貨架只剩5個可樂，小王在19/6/24日15:20:12向該貨架上架20個，預計放在貨架第4層；因為新貨架促銷，打折價3元。
首先，所有相關信息排列：
實際業務會比這個字段更多，全在一張表裡儲存雖然看上去清晰，但是缺點也很明顯——因為將主體相關的屬性、流水、維度等數據全部混在一起，勢必造成大量的數據冗餘。
我們按數據類型拆為屬性表和流水錶。
其中屬性表分為商品SKU和貨架；流水錶為上架操作過程。整理後如下：
首先，看一下商品表：
（1）商品屬性（類別，名稱等）跟商品流水（進貨、出貨）混在一起，可以進一步拆分。
（2）“倉庫剩餘個數”，可能進貨的要改、上架的要改、盤點的要改，多個地方都會對這個字段作用。這種情況可以通過實時計算，比寫入覆蓋的方式更為準確。
所以調整後會改為：
注：前臺展示的餘量實時計算，不落表。
可以看到商品流通和之前的上架表非常類似，只相差一個貨架編號。
假設我們把倉庫看做一個大貨架，設為0，兩表合併整理後：
再來看貨架表，“商品種類數”適用實時計算，不落表。（類似前文倉庫餘量計算）。
還有一個問題非常突出——商品詳情這欄內容特別多。
非結構化數據，不便處理，且與其他表內容重複（比如商品名稱和售價）。同樣的字段最好只在一個地方維護，避免表之間的數據衝突。商品名稱很明顯放在商品屬性裡。
那售價這個字段應該放在商品還是貨架上的商品詳情？
這其實跟業務模式相關，放在商品裡方便全局管理，但是單個貨架不能實現差別化定價；相反，放在貨架上，同一商品在不同貨架上可以設置不同售價，缺點是修改調整比較困難。
根據我們的業務情況，售價主要是統一管理，放在了商品屬性；折扣主要是單個貨架進行，所以折扣價放在了貨架的商品詳情。
調整後如下：
數據結構確認之後，頁面內容設計就比較清晰了：
【商品】
【貨架】
【貨架詳情】
【商品流轉】
注：在實際產品中，頁面入口可能帶有一些參數，比如上圖如果是點擊“進貨”按鈕的彈出框，就無需再手動選擇交易類型。
二、字段類型
前面從大的範圍上介紹了字段的劃分，細節上單個字段的類型、長度也需要加以關注。
一些常用的字段類型：
產品轉技術難度比較大，學習數據表結構就門檻低很多，對產品設計的作用也很明顯。本文會簡單介紹一些產品設計中會用到的數據表結構方面的思考，希望對各位有所幫助。
程序是怎麼運行的呢？
簡單來說，就是去指定的位置（表）取數據，完成運算，放到指定的位置（表）存起來或展示出來。
那麼，怎麼保證取到的/存到的數據是按我們預想的方式來的呢？這就涉及到表結構問題了。
數據表是由表名、表中字段、字段內容組成。本文主要圍繞字段劃分及字段定義兩個部分，介紹在產品設計中需要用到的表結構知識。
一、字段分類
要完成一個流程（運算），我們需要諸多數據（字段），這麼多字段是一張表還是多張表呢？
我們可以以商品上架為例，簡單分析一下。
比方說，倉庫現在還有可口可樂50個，進價2.5元，售價3.5元。
1號貨架只剩5個可樂，小王在19/6/24日15:20:12向該貨架上架20個，預計放在貨架第4層；因為新貨架促銷，打折價3元。
首先，所有相關信息排列：
實際業務會比這個字段更多，全在一張表裡儲存雖然看上去清晰，但是缺點也很明顯——因為將主體相關的屬性、流水、維度等數據全部混在一起，勢必造成大量的數據冗餘。
我們按數據類型拆為屬性表和流水錶。
其中屬性表分為商品SKU和貨架；流水錶為上架操作過程。整理後如下：
首先，看一下商品表：
（1）商品屬性（類別，名稱等）跟商品流水（進貨、出貨）混在一起，可以進一步拆分。
（2）“倉庫剩餘個數”，可能進貨的要改、上架的要改、盤點的要改，多個地方都會對這個字段作用。這種情況可以通過實時計算，比寫入覆蓋的方式更為準確。
所以調整後會改為：
注：前臺展示的餘量實時計算，不落表。
可以看到商品流通和之前的上架表非常類似，只相差一個貨架編號。
假設我們把倉庫看做一個大貨架，設為0，兩表合併整理後：
再來看貨架表，“商品種類數”適用實時計算，不落表。（類似前文倉庫餘量計算）。
還有一個問題非常突出——商品詳情這欄內容特別多。
非結構化數據，不便處理，且與其他表內容重複（比如商品名稱和售價）。同樣的字段最好只在一個地方維護，避免表之間的數據衝突。商品名稱很明顯放在商品屬性裡。
那售價這個字段應該放在商品還是貨架上的商品詳情？
這其實跟業務模式相關，放在商品裡方便全局管理，但是單個貨架不能實現差別化定價；相反，放在貨架上，同一商品在不同貨架上可以設置不同售價，缺點是修改調整比較困難。
根據我們的業務情況，售價主要是統一管理，放在了商品屬性；折扣主要是單個貨架進行，所以折扣價放在了貨架的商品詳情。
調整後如下：
數據結構確認之後，頁面內容設計就比較清晰了：
【商品】
【貨架】
【貨架詳情】
【商品流轉】
注：在實際產品中，頁面入口可能帶有一些參數，比如上圖如果是點擊“進貨”按鈕的彈出框，就無需再手動選擇交易類型。
二、字段類型
前面從大的範圍上介紹了字段的劃分，細節上單個字段的類型、長度也需要加以關注。
一些常用的字段類型：
產品轉技術難度比較大，學習數據表結構就門檻低很多，對產品設計的作用也很明顯。本文會簡單介紹一些產品設計中會用到的數據表結構方面的思考，希望對各位有所幫助。
程序是怎麼運行的呢？
簡單來說，就是去指定的位置（表）取數據，完成運算，放到指定的位置（表）存起來或展示出來。
那麼，怎麼保證取到的/存到的數據是按我們預想的方式來的呢？這就涉及到表結構問題了。
數據表是由表名、表中字段、字段內容組成。本文主要圍繞字段劃分及字段定義兩個部分，介紹在產品設計中需要用到的表結構知識。
一、字段分類
要完成一個流程（運算），我們需要諸多數據（字段），這麼多字段是一張表還是多張表呢？
我們可以以商品上架為例，簡單分析一下。
比方說，倉庫現在還有可口可樂50個，進價2.5元，售價3.5元。
1號貨架只剩5個可樂，小王在19/6/24日15:20:12向該貨架上架20個，預計放在貨架第4層；因為新貨架促銷，打折價3元。
首先，所有相關信息排列：
實際業務會比這個字段更多，全在一張表裡儲存雖然看上去清晰，但是缺點也很明顯——因為將主體相關的屬性、流水、維度等數據全部混在一起，勢必造成大量的數據冗餘。
我們按數據類型拆為屬性表和流水錶。
其中屬性表分為商品SKU和貨架；流水錶為上架操作過程。整理後如下：
首先，看一下商品表：
（1）商品屬性（類別，名稱等）跟商品流水（進貨、出貨）混在一起，可以進一步拆分。
（2）“倉庫剩餘個數”，可能進貨的要改、上架的要改、盤點的要改，多個地方都會對這個字段作用。這種情況可以通過實時計算，比寫入覆蓋的方式更為準確。
所以調整後會改為：
注：前臺展示的餘量實時計算，不落表。
可以看到商品流通和之前的上架表非常類似，只相差一個貨架編號。
假設我們把倉庫看做一個大貨架，設為0，兩表合併整理後：
再來看貨架表，“商品種類數”適用實時計算，不落表。（類似前文倉庫餘量計算）。
還有一個問題非常突出——商品詳情這欄內容特別多。
非結構化數據，不便處理，且與其他表內容重複（比如商品名稱和售價）。同樣的字段最好只在一個地方維護，避免表之間的數據衝突。商品名稱很明顯放在商品屬性裡。
那售價這個字段應該放在商品還是貨架上的商品詳情？
這其實跟業務模式相關，放在商品裡方便全局管理，但是單個貨架不能實現差別化定價；相反，放在貨架上，同一商品在不同貨架上可以設置不同售價，缺點是修改調整比較困難。
根據我們的業務情況，售價主要是統一管理，放在了商品屬性；折扣主要是單個貨架進行，所以折扣價放在了貨架的商品詳情。
調整後如下：
數據結構確認之後，頁面內容設計就比較清晰了：
【商品】
【貨架】
【貨架詳情】
【商品流轉】
注：在實際產品中，頁面入口可能帶有一些參數，比如上圖如果是點擊“進貨”按鈕的彈出框，就無需再手動選擇交易類型。
二、字段類型
前面從大的範圍上介紹了字段的劃分，細節上單個字段的類型、長度也需要加以關注。
一些常用的字段類型：
在字段類型上，我也遇到過一些坑，舉兩個例子說明一下：
我在P2P公司上班，用戶會發布很多借款，有個字段是表示借款類型，比如listingtype。
我們絕大多數的標都是普通標，穿插一點點其他類型。總類型不超過5種，所以當時字段類型是tinyint，範圍0-255。
後來有段時間我司發展與合作機構的合作標，當時我做配置系統，設計成每個合作單位分配一個listingtype。
跑著跑著有一天，研發反應過來了，說：總數就255，你再加就爆了。
後來的解決辦法是將合作標統一一個listingtype，然後同一類型下，每家單位再各自分配一個sublistingtype。
再舉一個例子，還是這個合作標的時候，上線之後，利息計算錯誤。研發查了一圈，是建表的時候利率字段用了默認的DECIMAL（18,0），導致導入數據時被四捨五入。
三、總結
當然，你可以說：表結構不是研發自定義的嗎？但這也不能全是研發的鍋，一是研發可能不清楚整個產品的規劃，或者說隨著業務變化，原本適合的字段類型變得不再適合。
另一方面，並不是所有產品都是從零開始，有的可能是後來加入進行老產品的版本迭代。這種產品在設計之前，瞭解原先的表結構及字段類型，就能避開很多坑。而且相比前端展示層，數據層上的坑，一般都是大坑，改起來也困難更多。
大家都知道，產品有技術背景會更方便溝通。技術入門也許太難，表類知識入門就簡單多了。
本文拋磚引玉，希望大家能往此方向去提煉一下自己，相信會給產品工作帶來較大助益。
作者：文二水，微信公眾號：文二水
本文由 @文二水 原創發佈於人人都是產品經理。未經許可，禁止轉載。
"