內容分類擴展性標籤設計

• 蘇格團隊
• 做者：YaoLang

角色：產品汪小T，程序員小C

---

小T：小C，有活幹了。咱們想作個在線題庫系統，老師能夠搜索題目來備課。

小C看着簡易的需求稿，心想，我一分鐘幾百萬上下，居然找我作這麼簡單的需求。建個題目表不就完事了。

小C：題目數據從哪裏來，包含什麼屬性？

小T：咱們第一期題目數據是從A公司那裏買過來的，題目包含正文，選項，答案，題型，難度。

小C：嗯，也就是我要建一張question表，包括這五個屬性。那題型和難度有哪些呢？

小T：題型有五種，單選，多選，判斷，填空，解答。難度有3種，簡單，通常，困難。用戶能夠根據題型或者難度來篩選。 小C拿着筆畫了一下：OK，表設計出來了

t_question表

字段	屬性	描述
uid	char(32)	惟一標示
body	TEXT	正文
options	JSON	題目選項
answer	TEXT	答案
type	int(11)	題目類型，1單選、2多選、3判斷、4填空、5解答
difficult	int(11)	題目難度，1簡單、2通常、3困難

小C：搜索根據body, options模糊匹配，而後篩選讓前端傳入type = 1或者difficult = 3 進行題型和難度的篩選

小T：哇，果真靠譜，那咱們上線吧。

---

小T：小C，咱們的題庫系統發到市場上有不少用戶反饋說題目量不太夠，最近咱們找到了B公司合做，但願能把B公司的題庫也整合到咱們的系統，數據的結構和A公司的很類似，你看下要弄多久。

小C心想，敢情這產品汪不生產題目，只是題目的搬運工啊。

小C：導一下數據就完事了。把接口文檔發我對接一下就行了。

小T：好，待會文檔發你。

拿到B公司的題目接口，題目總體結構不變，但是題型和難度的分類都比A公司多一點。題型有單選題，多選題，分析題，通常分解題，APP分解題。題型有簡單，通常，困難，極難。

小C心想：我去，我要以哪一個公司的題目分類做爲標準。因而找到了小T

小C：數據若是作整合的話，可不能夠將B公司的分析題，通常分解題，APP分解題變成咱們的解答題，極難不要，都變成困難。由於如今沒有定義一個標準，我不太好整合數據。

小T：那好吧，先按你說的去作。

---

自那之後，小T又找了兩家公司合做，讓小C整合數據。而且小T認爲其中一家公司的方法（配方法，消元法，排除法）和能力（推理能力，分析能力，計算能力）數據也是很重要的維度，但願能作補充。

小C崩潰了，我一分鐘幾百萬上下，居然找我來導數據。每次還要去看數據的分類值應該怎麼作整合。還常常要加字段。如今由於要接入那兩家公司的題庫數據，要將表修改爲

t_question表

字段	屬性	描述
uid	char(32)	惟一標示
body	TEXT	正文
options	JSON	題目選項
answer	TEXT	答案
type	int(11)	題目類型，1單選、2多選、3判斷、4填空、5解答
difficult	int(11)	題目難度，1簡單、2通常、3困難
ability	int(11)	能力屬性，1推理能力，2分析能力 。。。。
method	int(11)	方法屬性，1配方法，2消元法，3排除法。。。

1. 如今題庫有300W數據，將來還會不斷地增長，若是頻繁改表的話，線上會直接鎖表
2. 若是每一個分類我還要去看哪些值應該映射爲咱們定義的哪些值，後面確定會吃不消的，由於咱們沒有一套統一的標準。。。

小C意識到本身跳到了一個大坑中，原來這東西並無一開始想的這麼簡單。

通過仔細的思考，小C得出結論：

1. 行業內根本就沒有一套標準，必須針對變化點作擴展
2. 不一樣的公司題目的維度數據不同（如某公司多了能力與方法兩個維度）
3. 不一樣的公司同一維度的數據值不同（如B公司的題型和A公司不同）

專門針對標籤創建表

• 一個標籤分類下有多個標籤值
• 一道習題有多個標籤屬性

t_tag表

字段	屬性	描述
uid	char(32)	惟一標示
tag_name	varchar(64)	標籤分類
tag_key	varchar(64)	標籤key

t_tag_value表

字段	屬性	描述
uid	char(32)	惟一標示
tag_id	char(32)	標籤分類id
value_name	varchar(64)	標籤值名
value_code	varchar(64)	標籤值編碼

t_question_tag表

字段	屬性	描述
id	char(32)	惟一標示
tag_value_id	char(32)	標籤值id
question_id	char(32)	題目id

當一次查詢時，先將查詢到的題目id到t_question_tag表中查出tag_value_id集合。 標籤進行GROUP BY tag_id聚合後獲得如下json

[{
分類名：難度, 
分類key: difficult,
值列表:[{
    值名：簡單, 
    值編碼: 1
},{
    值名：通常, 
    值編碼: 2
},{
    值名：困難, 
    值編碼: 3
}]}
]
複製代碼

經過返回標籤聚合，能夠在前端展現

難度：簡單，通常，困難
題型：選擇題，判斷題，做文，完形填空。。。
方法：配方法，消元法。。。。
複製代碼

篩選時，傳入標籤key （difficult）,標籤value (1)獲得tag_value_id 而後能夠篩選出跟標籤綁定的題目。

拓展總結：

1. 當某張數據表將來可能數據量會很龐大的，不能由於需求變動頻繁地增長表的字段，考慮增長中間表的方式來進行拓展
2. 通常實體數據信息不肯定的時候，也能夠考慮使用NOSQL檢索，如設計成如下的文檔，就能夠利用NOSQL的數組查詢功能檢索標籤對應的實體。

{
    "uid":"",
    "description":"",
    "tag_ids":["標籤1","標籤2","標籤3"]
}
複製代碼

3. 該設計也能應用於電商中，如商品的分類篩選

顏色：黃色，藍色，綠色
尺碼：M，L，XL，XXL
風格：休閒，商務
複製代碼

4. 標籤只適合用於有限個數的分類，如文件大小，價格這些不固定的屬性是不能作成標籤的。
5. 標籤字段是不會有排序需求的，如按照某個分類進行order by。由於標籤訂位是有限分類，排序沒有任何的意義，標籤只能用來作篩選。若是必定要排序，建議另外計算標籤和其餘屬性計算出一個分數字段。

問題點：

1. 爲何標籤值要分紅標籤uid和標籤code呢

標籤code屬於多變的，能夠自定義，如讓簡單定義爲1，困難定義爲2。若是直接讓題目綁定1，極可能和其餘的分類衝突。如題型的1爲單選題。

2. 爲何要前端傳入key和value不直接傳標籤uid

會有一些場景須要業務自定義標籤，如省市區，用戶使用時更想用101100這種全國通用的地區編碼來作標籤篩選。

作到這裏，小C稍微鬆了一口氣，以後你來一個公司的數據，若是有新的分類，就能夠加標籤類別再加標籤值。若是同一分類下來新的值，先看一下分類的中文名是否是對應的上，對應不上新建標籤，而後讓產品去作標籤的整合或者就當成兩個不一樣的標籤來算。不再怕整合數據了。