> Usually though, you'd be interested a large graphs which include
> information for lots of records (e.g., nodes are individual users,
> or products, or whatever). A graph datatype is not well suited for
> that, because it'd store each graph as a single value, and updating
> the graph would mean rewriting that whole value. If you're e.g. doing
> social network analysis, and each new edge between two users requires
> you to pull the whole graph from disk, update it, and write it back,
> you'll probably hit problems once you reach a few hundred users or
> so… Which really isn't a lot for that kind of application.
Yes, I agree. Hence, I suggested keeping the nodes and links separate.
So, if you need to add a new edge, you just need to update the
adjacency lists.
What I think will work is more of a 'logical' graph i.e. Consider a
tuple in some table. To add it to a new/existing graph as a node, we
just need to add an adjacency list for it. For each edge that connects
the tuple to some other node, we add the corresponding entry in the
list.
Essentially, the idea is again, to separate the nodes and links,
hence, the actual node is accessed pretty infrequently as compared to
the links. Since they are separate, there is no need to pull out the
entire graph for updating a single edge. This was the fundamental
problem with my HStore based design.
Regards,
Atri
--
Regards,
Atri
l'apprenant
