要在数据库设计一个标签系统，给各个实体打上标签。
然后又需要可以体现层次关系，比如红黑树是属于数据结构标签的子标签这种结构。
还要考虑到相同意义的标签重定向的情况，比如线段树和区间树其实讲的是一个东西，另外就是像国际化或者大小写这样的，Trie，trie，字典树又是一个东西。
现在想法是，给标签设一个parent_id来指向父标签来表示层次性，另外设一个redirect_id来进行重定向来做同类标签，然后统一用英文来设标签最后通过翻译来解决不同语言的同义标签问题，因为这个标签可能也会作为百科词条这样的设计，所以如何解决同义标签问题确实比较纠结。
感觉想并查集一样了，不知道这样设计好不好，有没有更好的设计方法等，因为这个标签也可能会作为百科词条一样的功能，所以想问问一般实际开发中是怎么处理这类问题的。
題主這個設計基本可靠，有幾點分歧供探討：
標籤本身感覺是個平坦和鬆散的東西，分層次似乎不太搭。最多說標籤有個類別category，而不是層次，像segmentfault和很多網站都是如此。否則就搞成電商那種層次化分類了
標籤國際化有點奇怪，中國人也會設很多英文標籤，就像問題裡說的trie和字典樹，中國人都會叫。如果我做國際化，會把中文英文標籤分開來記錄，中文登入看到的標籤和英文登入看到的完全是兩回事。假設某人中文登入為某個實體加上了trie和字典樹兩個標籤，英文登入時會顯示沒有任何標籤，除非在英文情況下另建標籤
我現在是更傾向用mongodb、elasticsearch這種文檔型的nosql來儲存這種文章、標籤的東西。用關聯式資料庫特別是mysql（不支援陣列欄位）來搞類似的東西很痛苦，像帶著鐐銬跳舞
本人沒有相關產業經驗。
同意@manong 的答案，如果你用
parent_id來定義父子標籤關係，萬一哪天這個子標籤有可能同屬兩個不同的父標籤那就尷尬了。用類別來管理比較靈活（當然，如果你目前的業務不複雜的話，不建議考慮那麼長遠的事情）。標籤國際化這個…不能理解。 。
舉個例子：我打了個
Chrome的標籤，程式設計師都知道；結果國際化後變成铬，這就尷尬了…當然，有沒有國際化需求還得根據你們的業務來決定（畢竟增加了維護成本），我只是從程式設計師角度舉個例子。
redirect_id算是比較快速簡單的實現，靈活一點的可以建一個中間關係表。另外，關於你提到的這一點，需要有個字典表去表達這些關係（自然也就需要去人工維護），除非你用演算法去判斷。