問題タブ [materialized-path-pattern]

SQL では、ネストされたセットを使用して階層データを格納しました。私はFirebaseで同じことをしようとしています。理論的には、階層は "n" レベルの深さになる可能性がありますが、実際にはおそらく 5 ～ 7 レベルの深さになります。

私はかなりの研究をしました。このMongo DB ドキュメントでは、静的ツリーでネストされたセットのみを使用することを提案しています。私のデータは、時間の経過とともにかなり変化します。同じドキュメントは、具体化されたパスが進むべき道であるという結論につながります。

誰もこれを経験していますか？

マテリアライズド パスを使用して、SQl (私の場合は MySQL 5.7) にツリー構造を格納しています。パスをスラッシュで区切られたスラッグとして保存しています。私が読んだすべてのチュートリアルでは、行をパスでソートして正しい順序で抽出するように言われていましたが、パスの一部に同様のプレフィックスがある場合は機能しないようです。

いくつかのコード例:

今、パスでソートすると、間違った順序になります:

出力：

これは、ほとんどの (すべての?) 照合順序で - が / の前にあるために発生しているようです。

クレイジーなことは、UNIX の sort コマンドライン ユーティリティが正しいことを行うことです。すべてのパスをファイルに入れて並べ替えると、正しい出力が得られます。

MySQL でツリーを適切にソートする方法はありますか? unix の sort ユーティリティと同じ方法でソートするには? おそらく別の照合か何か？それとも他の裏技？

具体化されたパスの日付構造は次のようになります。

このデータを使用して、 Force-Directed-Tree のような力指向のツリー チャートを生成したいと考えています。

ただし、このタイプのチャートは次のような構造しか取りません。

ノートに含まれるリーフの数とノードのツリーの深さがわからないため、データをターゲット構造に変換する方法がわかりません。私はpythonを使用していますので、これに関する提案はありますか？どうもありがとう！

「エンティティ」と「エンティティ テンプレート」があります。最上位エンティティは、「templateId1」であるエンティティ テンプレートに関連付けられています。そこからエンティティは、ID を使用してパス内の別のエンティティに関連付けられます。私は効率的な方法で次のデータ構造に終わろうとしています:

構造の最初のインスピレーションは、MongoDB のドキュメントから得られました。

https://docs.mongodb.com/manual/tutorial/model-tree-structures-with-materialized-paths/

「エンティティ テンプレート」が最上位の親であるというわずかに異なるユース ケースがありましたが、「エンティティ」内ではユース ケースは同じです。どんな洞察も大歓迎です。