要在数据库设计一个标签系统，给各个实体打上标签。
然后又需要可以体现层次关系，比如红黑树是属于数据结构标签的子标签这种结构。
还要考虑到相同意义的标签重定向的情况，比如线段树和区间树其实讲的是一个东西，另外就是像国际化或者大小写这样的，Trie，trie，字典树又是一个东西。
现在想法是，给标签设一个parent_id来指向父标签来表示层次性，另外设一个redirect_id来进行重定向来做同类标签，然后统一用英文来设标签最后通过翻译来解决不同语言的同义标签问题，因为这个标签可能也会作为百科词条这样的设计，所以如何解决同义标签问题确实比较纠结。
感觉想并查集一样了，不知道这样设计好不好，有没有更好的设计方法等，因为这个标签也可能会作为百科词条一样的功能，所以想问问一般实际开发中是怎么处理这类问题的。
题主这个设计基本靠谱，有几点分歧供探讨：
标签本身感觉是个平坦和松散的东西，分层次似乎不太搭。最多说标签有个类别category，而不是层次，像segmentfault和很多网站都是如此。否则就搞成电商那种层次化分类了
标签国际化有点奇怪，中国人也会设很多英文标签，就像问题里说的trie和字典树，中国人都会叫。如果我做国际化，会把中文英文标签分开来记录，中文登录看到的标签和英文登录看到的完全是两回事。假设某人中文登录给某个实体加上了trie和字典树两个标签，英文登录时会显示没有任何标签，除非在英文情况下另建标签
我现在是更倾向用mongodb、elasticsearch这种文档型的nosql来存储这种文章、标签的东西。用关系数据库特别是mysql（不支持数组字段）来搞类似的东西很痛苦，像带着镣铐跳舞
本人没有相关行业经验。
赞同@manong 的答案，如果你用
parent_id来定义父子标签关系，万一哪天这个子标签有可能同属两个不同的父标签那就尴尬了。用类别来管理比较灵活（当然，如果你当前的业务并不复杂的话，不建议考虑那么长远的事情）。标签国际化这个……不能理解。。
举个例子：我打了个
Chrome的标签，程序员都知道；结果国际化后变成铬，这就尴尬了……当然，有没有国际化需求还得根据你们的业务来决定（毕竟增加了维护成本），我只是从程序员角度举个例子。
redirect_id算是一种比较快速简单的实现，灵活一点的可以建一个中间关系表。另外，关于你提到的这一点，需要有个字典表去表达这些关系（自然也就需要去人工维护），除非你用算法去判断。