学校のプロジェクトで b ツリーを使用してデータベースを実装する必要があります。データベースはオーディオ ファイル (曲) を保存するためのもので、特定のアーティストや特定のアルバムのすべての曲を要求するなど、さまざまなクエリを実行できます。
直感的なアイデアは、各フィールド(曲、アルバム、アーティストなど) に対して on b ツリーを使用することです。問題は、任意のフィールドの任意のメンバーを削除するように求められる可能性があることです。たとえば、特定のアーティストのすべての曲は、曲に対応する b ツリーで互いに近くにある必要はないことに注意してください。
私の質問は次のとおりです。他の b ツリーのすべての要素を反復処理する必要なく、そうする方法はありますか(作成者への削除が行われた後に曲を削除します) 。私が思いついたものはすべてブルートフォースのものであるため、コードだけのアイデアを探しているわけではありません。
これは私の理解であり、完全に正しいとは限りません。
通常、データベースの実装では B ツリーがインデックスに使用されるため、ユーザーにすべての列にインデックスを付けるよう強制したい場合を除き、フィールドごとにデフォルトで B ツリーを作成する必要はありません。このように多数のインデックスがあると、ほぼすべてのケースで読み取りが高速になりますが (すべてにインデックスがあれば、完全なテーブル スキャンを実行する必要はありません)、挿入/更新/削除が非常に遅くなります。ツリーごとに更新されます。ご存じのとおり、最新のデータベースでは少なくとも 1 つのインデックス (主キー) が必要になるため、主キーのキーと適切なノードへのポインターを持つ B ツリーが少なくとも 1 つ必要になります。
B ツリー インデックス内のすべてのノードには、それが表す完全なオブジェクトへのポインタ/参照が必要です。
今後作成されるインデックスには、曲名、アーティストなど、インデックスで指定した属性が含まれますが、対応するノードへのポインター/参照は引き続き含まれます。したがって、たとえば曲のタイトルを変更する場合、すべてのインデックスが参照する参照ノードを変更する必要があります。変更された参照を属性として持つインデックスがある場合は、そのインデックス自体の値を変更する必要があります。
残念ながら、削除/更新時に他の B ツリーを強引に通過する必要があるというあなたの考えは正しいと思います。これは、多くのインデックスを使用することの欠点の 1 つです (更新/削除時間が遅くなります)。参照されているノードを削除するだけでは、削除されたオブジェクトへのポインタが残る可能性が高く、(言語によっては) なんらかの形式の NullPointerException が発生します。これを防ぐには、参照をすべてのツリーから削除する必要があります。
ただし、インデックスのフル スキャンを実行する方が、テーブルのフル スキャンを実行するよりもはるかに優れていることに注意してください。