要在数据库设计一个标签系统,给各个实体打上标签。
然后又需要可以体现层次关系,比如红黑树
是属于数据结构
标签的子标签这种结构。
还要考虑到相同意义的标签重定向的情况,比如线段树
和区间树
其实讲的是一个东西,另外就是像国际化或者大小写这样的,Trie
,trie
,字典树
又是一个东西。
现在想法是,给标签设一个parent_id
来指向父标签来表示层次性,另外设一个redirect_id
来进行重定向来做同类标签,然后统一用英文来设标签最后通过翻译来解决不同语言的同义标签问题,因为这个标签
可能也会作为百科词条这样的设计,所以如何解决同义标签问题确实比较纠结。
感觉想并查集一样了,不知道这样设计好不好,有没有更好的设计方法等,因为这个标签也可能会作为百科词条一样的功能,所以想问问一般实际开发中是怎么处理这类问题的。
質問のデザインは基本的に信頼できますが、議論のためにいくつかの違いがあります。
レーベル自体が平坦でゆるい感じがして、レイヤーがうまく合っていない気がします。セグメントフォールトや多くの Web サイトの場合のように、ラベルには階層ではなく、せいぜいカテゴリがあります。そうしないと、電子商取引
タグの国際化は少し奇妙です。質問にあるトライと辞書ツリーのように、中国人も英語のタグを多く設定します。国際化を行う場合は、中国語と英語のラベルを別々に記録します。中国語でログインしたときに表示されるラベルは、英語でログインしたときに表示されるものとはまったく異なります。誰かが中国語でログインし、エンティティに trie と Dictionary ツリーという 2 つのラベルを追加したとします。英語でログインすると、別のラベル
私は今、このような記事やタグを保存するために mongodb や elasticsearch などのドキュメント型 NoSQL を使用する傾向にあります。リレーショナル データベース、特に mysql (配列フィールドをサポートしていない) で同様のことを行うのは、足かせを付けて踊るようなもので非常に苦痛です
私には関連業界での経験がありません。
@manong の回答に同意します。
parent_id
を使用して親子タグ関係を定義すると、いつか子タグが 2 つの異なる親タグに属する可能性があると恥ずかしいことになります。カテゴリを使用して管理するほうがより柔軟です (もちろん、現在のビジネスが複雑でない場合は、そのような長期的なことを考慮することはお勧めできません)。タグの国際化は...理解できません。 。
例:
Chrome
タグを付けましたが、プログラマーは皆それを知っていますが、国際化後は铬
になってしまい、恥ずかしいです...もちろん、国際化の必要があるかどうかは関係ありません。に依存します (結局のところ、メンテナンスコストが増加します)。プログラマーの観点から例を示しているだけです。
redirect_id
は比較的高速で単純な実装です。より柔軟な場合は、中間の関係テーブルを構築できます。また、ご指摘の点ですが、アルゴリズムで判断しない限り、これらの関係を表現するには辞書が必要になります(当然手作業によるメンテナンスが必要になります)。