問題描述

要在數(shù)據(jù)庫(kù)設(shè)計(jì)一個(gè)標(biāo)簽系統(tǒng)，給各個(gè)實(shí)體打上標(biāo)簽。然后又需要可以體現(xiàn)層次關(guān)系，比如紅黑樹是屬于數(shù)據(jù)結(jié)構(gòu)標(biāo)簽的子標(biāo)簽這種結(jié)構(gòu)。

還要考慮到相同意義的標(biāo)簽重定向的情況，比如線段樹和區(qū)間樹其實(shí)講的是一個(gè)東西，另外就是像國(guó)際化或者大小寫這樣的，Trie，trie，字典樹又是一個(gè)東西。

現(xiàn)在想法是，給標(biāo)簽設(shè)一個(gè)parent_id來指向父標(biāo)簽來表示層次性，另外設(shè)一個(gè)redirect_id來進(jìn)行重定向來做同類標(biāo)簽，然后統(tǒng)一用英文來設(shè)標(biāo)簽最后通過翻譯來解決不同語(yǔ)言的同義標(biāo)簽問題，因?yàn)檫@個(gè)標(biāo)簽可能也會(huì)作為百科詞條這樣的設(shè)計(jì)，所以如何解決同義標(biāo)簽問題確實(shí)比較糾結(jié)。

感覺想并查集一樣了，不知道這樣設(shè)計(jì)好不好，有沒有更好的設(shè)計(jì)方法等，因?yàn)檫@個(gè)標(biāo)簽也可能會(huì)作為百科詞條一樣的功能，所以想問問一般實(shí)際開發(fā)中是怎么處理這類問題的。

問題解答

題主這個(gè)設(shè)計(jì)基本靠譜，有幾點(diǎn)分歧供探討：

標(biāo)簽本身感覺是個(gè)平坦和松散的東西，分層次似乎不太搭。最多說標(biāo)簽有個(gè)類別category，而不是層次，像segmentfault和很多網(wǎng)站都是如此。否則就搞成電商那種層次化分類了

標(biāo)簽國(guó)際化有點(diǎn)奇怪，中國(guó)人也會(huì)設(shè)很多英文標(biāo)簽，就像問題里說的trie和字典樹，中國(guó)人都會(huì)叫。如果我做國(guó)際化，會(huì)把中文英文標(biāo)簽分開來記錄，中文登錄看到的標(biāo)簽和英文登錄看到的完全是兩回事。假設(shè)某人中文登錄給某個(gè)實(shí)體加上了trie和字典樹兩個(gè)標(biāo)簽，英文登錄時(shí)會(huì)顯示沒有任何標(biāo)簽，除非在英文情況下另建標(biāo)簽

我現(xiàn)在是更傾向用mongodb、elasticsearch這種文檔型的nosql來存儲(chǔ)這種文章、標(biāo)簽的東西。用關(guān)系數(shù)據(jù)庫(kù)特別是mysql（不支持?jǐn)?shù)組字段）來搞類似的東西很痛苦，像帶著鐐銬跳舞

本人沒有相關(guān)行業(yè)經(jīng)驗(yàn)。

贊同@manong 的答案，如果你用parent_id來定義父子標(biāo)簽關(guān)系，萬一哪天這個(gè)子標(biāo)簽有可能同屬兩個(gè)不同的父標(biāo)簽?zāi)蔷蛯擂瘟恕Ｓ妙悇e來管理比較靈活（當(dāng)然，如果你當(dāng)前的業(yè)務(wù)并不復(fù)雜的話，不建議考慮那么長(zhǎng)遠(yuǎn)的事情）。

標(biāo)簽國(guó)際化這個(gè)……不能理解。。舉個(gè)例子：我打了個(gè)Chrome的標(biāo)簽，程序員都知道；結(jié)果國(guó)際化后變成鉻，這就尷尬了……當(dāng)然，有沒有國(guó)際化需求還得根據(jù)你們的業(yè)務(wù)來決定（畢竟增加了維護(hù)成本），我只是從程序員角度舉個(gè)例子。

redirect_id算是一種比較快速簡(jiǎn)單的實(shí)現(xiàn)，靈活一點(diǎn)的可以建一個(gè)中間關(guān)系表。

線段樹和區(qū)間樹其實(shí)講的是一個(gè)東西，另外就是像國(guó)際化或者大小寫這樣的，Trie，trie，字典樹又是一個(gè)東西。

另外，關(guān)于你提到的這一點(diǎn)，需要有個(gè)字典表去表達(dá)這些關(guān)系（自然也就需要去人工維護(hù)），除非你用算法去判斷。