On Sun, Apr 28, 2013 at 1:06 AM, Atri Sharma <atri.jiit@gmail.com> wrote:
> Inspired by the awesome work done by Oleg sir in HStore, I have been thinking about making a graph data type as an
extensionin postgres.
>
> I have been reading about graph databases and how storing data in graphs can lead to some really awesome
functionalitiessuch as social network analysis, recommender systems, network management.
>
> Essentially, connected data can be represented effectively as a single data item, which can be used for further
analysis.
>
> This is in line with my agenda of adding more analytics functionalities in postgres.
>
> I have been thinking about designing the data type as adjacency sets, associating the adjacency list for each node as
avalue with node identifier as the key.
>
> This should be able to build over HStore, using HStore to associate adjacency list with its node identifier.
>
> The format could be:
>
> <node identifier> => <adjacency list> <node identifier> => <adjacency list> '\0'
>
> So,
>
> "node1" => "node2/node3/node4","node2" => "node1/node5/node6","node3" => "node1/node4/node5" '\0'
>
> This can be for unweighted graphs, we can add support for weighted graphs as well.
>
> Thoughts/comments/advice please?
It's probably pretty easy to add this, but I think the question is
what would make it better than storing the same representation in a
text field. Obviously you get validation that the input is in the
correct format, but you could do that with a CHECK constraint, too, or
otherwise handle it in the application. So I think the really
interesting question is: what operations would you support on this
data type?
One of the problems you're likely to run into if you store the whole
graph as a single object is that it may make many of the things you
want to do with it not very efficient.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company