0

そのため、リレーショナル データベースへのオブジェクトのシリアル化に関する特定の問題について熟考していました。

N個の異なるオブジェクトがあり、すべてが特定のインターフェースを実装しているとしましょう（そのための有向グラフインターフェース。これらは getIncomingNodes() 、 getOutgoingNodes() などのメソッドを提供します）。

そのような各オブジェクトがリレーショナル データベースに対応するテーブルを持っている場合、そのような有向グラフをリレーショナル データベースにシリアル化するベスト プラクティスは何ですか?

N が小さいと仮定すると (私の場合は N=3)、別のテーブルに含まれる可能性のあるすべてのリンクを分解しました。たとえば、オブジェクト x から y に向かうリンクのテーブルは次のようになります。

tbl_links_X_Y {
int X_id
int Y_id
}

問題は、そのようなテーブルが N^2 個得られることです。あまり効率的ではなく、将来 N+1 オブジェクトに拡張するのが難しいことが判明する可能性があります。

その問題を解決するパターンはありますか？(リレーショナル データベースに関係なくても、喜んでお知らせします...)

ありがとう！

4

3 に答える 3

0

最近、NoSQL フレームワークがOrientDB
を呼び出すことに遭遇しました。その DB エンジンはこの問題を正確に処理します。これは、SQL クエリを実行し、別のオブジェクトが指すオブジェクト (隣接する頂点など) を遅延ロードする機能を備えたグラフ データベースです。

残っていることの 1 つは、このフレームワークのパフォーマンスを従来の SQL データベースのパフォーマンスと比較することです。(もちろん、従来の SQL データベースでクエリに対する生の応答からオブジェクトを構築するのにかかる時間を考慮する必要があります..)

この比較の結果が得られたら、ここに投稿します。

于 2012-06-18T14:22:05.507 に答える
0

グラフがリレーショナル モデルに従うように「強制」することもできます。

テーブル グラフ { integer vertexid, varchar edgelist }

edgelist は区切り文字ベースの文字列にすることができます: たとえば、エントリが {incident vertex,weight} である {2,10}、{3,12}、{4,13} など、
テーブル内の行数は次のようになります。 O(n^2) ではなく O(n)

次に、アプリケーションがグラフを読み取って何らかの操作を実行するときに、メモリ内にグラフを作成し、同じことを行う必要があります。

于 2012-06-15T13:23:07.673 に答える
0

You can easily store the class of the objects (table names) in the connection table as well.

tbl_links_X_Y {
int X_id
int Y_id
enum {user, customer, product} X_type
enum {user, customer, product} Y_type
}

They you would just include this in the where or join clause.

I guess this would not be a strictly relational database, since you can't (?) use/enforce foreign key constraints.

于 2012-06-04T12:42:04.323 に答える