問題描述

要在數據庫設計一個標簽系統，給各個實體打上標簽。然后又需要可以體現層次關系，比如紅黑樹是屬于數據結構標簽的子標簽這種結構。

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

現在想法是，給標簽設一個parent_id來指向父標簽來表示層次性，另外設一個redirect_id來進行重定向來做同類標簽，然后統一用英文來設標簽最后通過翻譯來解決不同語言的同義標簽問題，因為這個標簽可能也會作為百科詞條這樣的設計，所以如何解決同義標簽問題確實比較糾結。

感覺想并查集一樣了，不知道這樣設計好不好，有沒有更好的設計方法等，因為這個標簽也可能會作為百科詞條一樣的功能，所以想問問一般實際開發中是怎么處理這類問題的。

問題解答

題主這個設計基本靠譜，有幾點分歧供探討：

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

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

我現在是更傾向用mongodb、elasticsearch這種文檔型的nosql來存儲這種文章、標簽的東西。用關系數據庫特別是mysql（不支持數組字段）來搞類似的東西很痛苦，像帶著鐐銬跳舞

本人沒有相關行業經驗。

贊同@manong 的答案，如果你用parent_id來定義父子標簽關系，萬一哪天這個子標簽有可能同屬兩個不同的父標簽那就尷尬了。用類別來管理比較靈活（當然，如果你當前的業務并不復雜的話，不建議考慮那么長遠的事情）。

標簽國際化這個……不能理解。。舉個例子：我打了個Chrome的標簽，程序員都知道；結果國際化后變成鉻，這就尷尬了……當然，有沒有國際化需求還得根據你們的業務來決定（畢竟增加了維護成本），我只是從程序員角度舉個例子。

redirect_id算是一種比較快速簡單的實現，靈活一點的可以建一個中間關系表。

線段樹和區間樹其實講的是一個東西，另外就是像國際化或者大小寫這樣的，Trie，trie，字典樹又是一個東西。

另外，關于你提到的這一點，需要有個字典表去表達這些關系（自然也就需要去人工維護），除非你用算法去判斷。