問題タブ [hierarchy]

スレッド化されたコメントを支援するために、アプリケーションでPostgreSQL のLtree モジュールを使用することを検討しています。スレッド化されたコメントに使用するためにしばらく注目していました。コメントとその返信を非表示にする場合など、ノードとその子を更新する必要がある場合に役立つと思います。

ltree (またはそれに似たもの) を従来の隣接リスト ("comment_id"/"parent_comment_id") と組み合わせると便利だと思います。

ltree の使用に飛び込む前に、いくつか疑問に思っていることがあります。

1. ltree を使用していますか、または使用したことがありますか? それは「生産準備完了」と呼ばれるものですか？
2. もしそうなら、それを使ってどのような問題を解決しましたか? うまくいきましたか？
3. スレッド化されたコメント システムに適していると思いますか?
   4. 使用した場合、パスの「テキスト」部分には何を使用しましたか? 「Top.Astronomy.Cosmology」を使用する DMOZ の例のようなものを設定しましたか、それとも主キー「1.403.29.5」のようなものに基づいていますか?
   5. これを行うより良い方法はありますか？ネストされたリストのアプローチを使用するのは少し緊張しています-私が読んだすべてのことは、UPDATESまたはINSERTSですべてがホットではないことを示唆しています(すべてを並べ替える必要はありませんか?)。私も CS 専攻ではありません。そのようなデータ構造は、将来忘れてしまうかもしれません。ネストされたリストをコメントなどに使用している人はいますか?

参考になれば、私が検討しているスキーマは次のとおりです。

ltree で使用される「パス」列は、次のようになります。

パスで主キーを使用することに問題はありますか? ノード自身の主キーをパスに含める必要がありますか? もしそうなら、制約として機能する一意のインデックスを配置することは理にかなっていますか?

バージョンの異なる 2 つのオブジェクトを比較し、それらの違いを UI に表示したいと考えています。

まず、メソッドを呼び出して、2 つのオブジェクトに違いがあるかどうかを確認します

メソッドは次のとおりです。

上記のメソッドが true を返す場合、GetDifferencesメソッドを呼び出して次の違いを取得します。

違いごとに、ObjectDifference 型のオブジェクトを作成し、それを配列に追加します。強調表示された部分は、私が立ち往生しているものです! オブジェクトに別の複雑なオブジェクトが含まれている場合、私のプログラムは違いを示しますが、それがどのタイプに属しているかはわかりません

たとえば、タイプ Name の 2 つのオブジェクトがあります。

2つのオブジェクトを比較している間、私が得る出力は単純です-

• firstname- ジョン・メアリー
• LastName-クーパーロー
• officeNo- 22222 44444
• MobileNo- 989898 089089
• HomeNo- 4242 43535

officeNoタイプの階層PhoneNumberが失われました。これは、表示するのに重要です。

差分を作成しながら、このタイプのツリーを維持するにはどうすればよいですか? 私の問題を理解できることを願っています。

私は日々の開発で多くの階層を扱っています。ファイルシステム、AutodeskMayaのネストされたDAGノードなど。

オブジェクトの階層をトラバースして比較するために特別に設計されたPython用の優れたモジュールはありますか？

特に興味深いのは、2つのほぼ同一の階層間で「あいまいな」比較を行う方法です。これを行う理由のいくつかは、アニメーションを一方から他方に転送するために、2つの異なるキャラクターからのMayaの2つのノード階層を一致させるためです。

私が読んでいることに基づいて、2つのノード名が互いにどれだけ近いかを比較するために、名前のしきい値（自分で作成できるもの）を持つものがおそらく必要になるでしょう。次に、子ノードが階層に表示される順序をオプションで無視する方法が必要です。最後に、ノードが階層の上下にわずかに移動した可能性がある場合に備えて、深度のしきい値を処理する必要があります。

「XML スプレッドシート 2003 (*.xml)」として保存するときに Excel が生成するものに基づいた XML ドキュメントがあります。

スプレッドシート自体には、ラベルの階層を持つヘッダー セクションが含まれています。

この階層はワークブックのすべてのシートに存在し、ほぼどこでも同じように見えます。

Excel XML は、通常の HTML テーブルとまったく同じように機能します。(<row>を含む<cell>)。私はすべてをそのようなツリー構造に変換することができました:

しかし、ここに複雑さがあります：

• 複数のワークシートがあるため、それぞれにツリーがあります
• 階層は各シートでわずかに異なる場合があり、ツリーは等しくありません (たとえば、シート 2 には "a113" があり、他のシートにはありません)。
• ツリーの深さは明示的に制限されていません
• ただし、ラベルはすべてのシートで同じであることを意図しているため、グループ化に使用できます

これらの別々のツリーを次のようなものにマージしたいと思います。

理想的には、Excel XML から 3 つの構造を構築する前に、マージを実行できるようにしたいと考えています (これを開始していただければ、それは素晴らしいことです)。しかし、これをどのように行うのか見当がつかないので、ツリーが構築された後のマージ (つまり、上記の状況) は問題ありません。

御時間ありがとうございます。:)

次 の
テーブル が あり ます 。 _ _ _ また、最後の子カテゴリにはアイテムを含めることができるため、最後のカテゴリの子だけがその下にアイテムを表示します。 ビューはツリービューのようになり、アイテムをクリックすると新しいページに移動します。 私は次のように書きました：

しかし、これは 1 レベルの構造を表しています。
私の質問は、それをツリー ビューとして作成する方法です。

現在、System.DirectoryServices 名前空間を使用して DirectoryEntry オブジェクトを作成し、階層全体をループして情報を収集するアプリケーションを開発しています。

階層内の各 DirectoryEntry オブジェクトの子エントリの数がわからないため、 Children プロパティを介してスパイダーに N 個のネストされたループを作成することはできません

これが私の擬似コードの例です:

私の質問は、オブジェクト内のサブディレクトリの数がわからない場合に情報を収集するためのループを作成する最良の方法は何ですか?

(これは、オブジェクト階層がわからない任意のタイプのオブジェクトに適用できます)

FirstName > MiddleName > LastName 階層があるとしましょう (質問のために、最大 10k 行)。これは、「John > Mary-Anne > Eddy」または「Eddy > John > Jacob」の行を持つことができることを意味します。ポイントは、階層がほとんど意味をなさず、ユーザーにとって非常になじみがないことです (たとえば、[国] > [州] > [都市] 構造とは異なります)。

非常に構造化されておらず混乱しているため、ユーザーにオートコンプリート入力ボックスを提供したいと考えています。入力すると、可能な部分文字列の一致を検索する必要があり、検索文字列をあるレベルで「ルート化」すると、結果がそのレベルより下に制限されます。

さて、「John」という名前の人がたくさんいるので、「John」と入力しても次のような結果しか返されないというのはほとんど意味がありません。

• ジョン > アレン > アレクサンダー
• ジョン > アレン > バーシャウィッツ
• ジョン > アレン ... 100 回繰り返す ...

一意の行 "Jason > John > Smith" が表示されないためです。

代わりに、次のようなものが返されるはずです (「*」は、「この下にさらに多くの行が存在する」というユーザーへの任意の指標にすぎません)。

• ジョン > アレン > *
• ジェイソン > ジョン > スミス
• マイク > ジョン > *
• メアリー > エレナ > ジョナソン

「John > Al」と入力すると、結果は「John >」の下にあるものに限定されますが、上記と同様にグループ化する必要があります。

説明が明確であることを願っています。要件は少し緩いです。人がツリーを検索して自分が求めているものを見つけることができるように、合理的なものだけです。

現在、行内の検索語を検索し、その位置を把握し、部分文字列化、グループ化、および順序付けを行って上記の結果を取得する興味深い SQL がありますが、十分に機能していません。

私は、典型的な LAMP スタック (Oracle を除く) でこの問題を解決しようとしています。共有ホスティングではないため、サーバーを完全に制御できます。データは数週間ごとに少量ずつ変更され、検索結果は妥当な期間、古いままになる可能性があります (たとえば、検索インデックスを更新する cron は問題外ではありません)。

これはこの質問に関連しています。例えば、この本、と考えさせられた。[Agriculture]およびの両方の子である代わりに[Other]、ツリー[Books > Catalogs > Agriculture]および[Business & Industrial > Agriculture & Forestry > Other]でそれぞれ、それらのレベルをタグとして持つだけで独立できます。

eBay のような Web サイトでは、データが適切に正規化されている場合、タグ [Agriculture付きのすべてのレコードをリストするパフォーマンス コストと、カテゴリCatalog]内のすべてのレコードをリストするパフォーマンス コストを大幅に上回るでしょうか?[Books > Catalogs > Agriculture]

これはおそらくばかげた質問だと思います (いや、次の eBay をプログラミングしているとは思いません) が、この好奇心を振り払うことはできません。誘惑; _ だから、後でばかげたことや無意味なことをするよりも、今はばかげているように聞こえて、自分の誤解を十分に把握したいのです。