在一些B端後台中，最基礎的就是字段了。除了“系統字段”、“業務字段”、“管理型字段”、“規則型字段”之外，還可以在通用的業務場景中按照輸入類和系統類再細分，本文作者從這兩個方面進行了分析，一起來看一下吧。

輸入和選擇控件果然鴿了，寫點偏業務的。

01 字段 Field

前陣子在一個群裡參與了關于「字段（Field）」的讨論。

無論是在黑帕雲、飛書多維表格、維格表、Airtable 還是在一些 B 端後台中，最基礎的就是字段。

有個文章對字段做了區分，分為“系統字段”、“業務字段”、“管理型字段”、“規則型字段”，定義是：

• 業務型字段：體現業務要求的字段，承載業務信息的展示。
• 系統型字段：系統交互之間的的請求日志信息字段，如系統主鍵、業務 ID、創建時間、創建人、版本号、最後修改時間、最後修改人等。以及系統之間的交互的請求編号、請求時間、請求相應信息等。
• 管理型字段：為了管理需要設置的字段，如操作時間、操作人、日志信息、操作意見、備注等。
• 規則型字段：系統為了某一規則而存續的字段。比如商品是即将下架的産品，可以設置下架時間、庫存量等，自動觸發後将商品下架。

這樣的方式非常适用于一些後台産品設計，很好和技術去溝通需求。

在這個基礎上，我想補充一些更通用的字段類型和字段格式。

在通用的業務場景中可以按照輸入類和系統類兩個大類去往下根據不同業務來再細分。

這兩個很好區分：需要業務人員填寫的就是輸入類，自動計算的則是系統類。

一般來講，系統字段都是指自動生成的，比如說修改時間、創建時間、流水号、創建人、操作人。

輸入類字段都是可以編輯的。

02 輸入類字段 Input Type Fields

輸入類字段再往下分，首先是根據數值進行分類。

常見的數值類型有以下幾種：

在确定了數值類型之後，可以對數值進行一些格式填寫的校驗，不同的數值類型有不同的校驗方式。

其中有兩個通用的是：

1. 「必填」校驗：是否允許這個字段為空。
2. 「重複」校驗：是否允許這個字段值和其它值重複，如果不允許重複則無法保存或提交，常見于錄入線索聯系人手機号或身份證、商品編碼等場景，比如要求身份證号碼必填并不允許重複，避免了重複錄入。

其它的校驗要根據字段值的結果進行區分。

1. 字符串 String

字符串通常可以一些正則表達式用來做以下業務常見格式的校驗：郵箱手機号身份證号碼網址。

這幾個類型都很好理解，其中要特殊說明一下「身份證号碼」類型。

大家知道，身份證号碼最後一位可以是 X 的，當時我們在做這個校驗規則的時候沒有了解正規的身份證号碼的 X 應該是大寫還是小寫。

有用戶就問了，這個 X 是否大小寫敏感？我看了一下，當時沒有做大小寫敏感。正規的身份證号碼 X 應該是大寫，也就是說我們輸入小寫 x 也是會通過校驗可以順利提交的。

如果不校驗的話，會發生什麼？——用戶因為按照身份證号碼字段設置了自動化的觸發，用“線索表”的身份證号碼去自動查詢“機會表”客戶的身份證，如果已經存在，就不會在機會表中新增這個聯系人，而是直接更新這個聯系人的其他信息。而自動化查詢時是大小寫敏感的，也就是說如果在“機會表”中， 假設有一個 “61010119941120003X” 的身份證号，如果銷售再在“線索表”錄入了“ 61010119941120003x”就會把這條數據自動觸發重複錄入到機會表中。

現在的問題是要解決重複錄入，重複的根源是身份證格式校驗要更精确。一拍腦門的做法可能是會告訴開發，在校驗身份證時，要大小寫敏感，必須要填寫大寫”X”才能通過校驗。

但是站在用戶的角度思考，這種處理方式就很惡心，因為“X”要大寫這件事不是一個熱知識。我們需要保證效率，而不是我們知道用戶錯了，我們會改，但我們就是要讓用戶自己改。

所以，我想到了更優雅的解決方式：如果用戶輸入了小寫的“x”，在存數據時，我們主動幫用戶修正為大寫的“X”。

2. 數字 Number

對數字進行數值校驗時，首先需要設置數字的格式。

其次，如果業務需要，可以用最大最小值來限制數字的輸入範圍。

3. 貨币 Currency

貨币字段和數字字段很像，都是隻允許輸入數字，區别是貨币沒有百分比顯示的開關，貨币字段能夠設置貨币符号，小數點位數至多隻允許設置四位。

4. 日期和日期時間 Date&Date Time

在不同的業務場景中對日期還是時間有不同的需求，比如在一些會議時間中就需要「日期時間」，在一些合同簽訂場景則需要的隻是「日期」。

二者都可以參與如 DateAdd、DateTime_Diff 這樣的日期運算。

關于多時區協作的問題可參考之前這篇文章《多時區協作如何保證時間不會産生歧義》。

默認值、支持時間、必填都比較基礎，就不用再寫了。

簡單寫一下關于日期格式校驗一些總結。

當時在做這個功能設計的時候，模拟了以下場景：

• 某旅遊團隻允許 18 歲-65 歲購買，出生日期早于 2003 年，晚于 1956
• 某博物館門票預定隻能購買第二天門票
• 酒店預定開始日期隻能預定最近 7 天（不含今天）
• 管理發票的回款，在填寫回款明細的時候，回款日期不能超過今天。
• 機票回程日期不能早于啟程日期
• 酒店預定結束日期不能早于開始日期

比較清楚的是，可以将以上場景收斂為三個分類：

1. 某個具體的日期參與的校驗範圍
2. 動态的“今天”參與的校驗範圍
3. 其它日期字段字段值（動态值）參與的校驗範圍

從業務的角度和成本考慮，對“今天”的需求概率會更高并且成本适中，所以在 Phase1 中， 做了前兩個分類的功能。

在應用管理員設置校驗時，可以設置這些規則：早于晚于在範圍内是不是

範圍可以選擇為：

• 指定日期：可以根據字段類型設置指定的日期或日期時間
• 填寫日期（“今天”）
• 填寫日期前（“今天”）：選擇這項後，可以動态設置範圍是填寫日期前[1,3650]區間的整數
• 填寫日期後（“今天”）：選擇這項後，可以動态設置範圍是填寫日期後[1,3650]區間的整數

提供以上幾種的規則和範圍，就能覆蓋除了需要其他日期字段值的任何校驗場景了。

5. 選擇 Select

選擇在表單中非常常見，可以分為單選和多選。

單選的表現形式有以下兩種：Select 和 Radio Button。

03 系統字段 System Fields

對于系統類字段再細分下去是系統自動生成的基礎信息，就是創建人、創建時間、修改人等，但是還有幾類，一個是公式計算的，比如商品價格*數量這種公式。

如果已經接觸了關系型數據庫，知道表和表之間的關系，那就需要了解以下兩個字段：

1. 「聚合（Rollup）」：用于計算所選數據的彙總、求平均值、最大、最小值
2. 「引用Lookup」：引用它表的數據

04 寫在最後

以上就是基本的字段的幾種類型，在 B 端産品中，這些字段類型非常常見。

複雜高級的字段後續會繼續再寫，比如地址字段（Address）、多級選擇（Multi-Select）、動态關聯（Dynamic Link Record）。

作者：高拉，高拉

本文由 @高拉 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部