> 1. We created JSON and XML types as ways of storing data that has a robust
> validation system.
>
> They're still, in a sense, just "plain old text", but it's "plain old text"
> that the user can be certain satisfies the respective rules for
> representations.
Yes, although, I feel that we can use JSON to port a graph's data out
of the database.
> I suspect that the best answer is NOT one where a graph is represented as a
> value in a table; that has the implication that modifying The Graph requires
> altering a single tuple, and that seems likely to become a horrible
> bottleneck. I'm suspicious that using HSTORE leads down that path, where
> you'll have a database that has a table with just one tuple in it, and where
> it's nearly impossible to alter that tuple.
I agree, hence, I have dropped the idea of building it completely over HStore.
> I'm having a hard time thinking about what it looks like to have a graph as
> table except to effectively compose the graph as a set of nodes, one tuple
> per node, and I'm not sure that a new data type has anything to contribute
> to that.
I can think of three points:
1) We can maintain pointers to tuples which are nodes in a graph
instead of copying over the actual data. This idea is based on the
assumption that node data access will be very specific i.e. accessing
actual data of nodes happens very less, for most analysis we are more
interested in the linkage.
2) In continuation of the above point, the more frequently accessed
areas are the link details, or in my current plan, the adjacency
lists. This could be maintained in a data structure by the data type,
with low overheads of updating, traversal and insertion.
3) The data type shall have in built support for common operations on
graphs. The user can call them directly and hence shall be saved the
overhead of designing his own data structures and functions.
> The one place where I *could* see a special type having a contribution is
> for there to be a data type that can contain an arbitrary number of links.
> That means you have one tuple per node, and, instead of needing a tuple for
> each link between nodes, you have one attribute indicating *all* the links.
> (And "interesting" is for that one attribute to be usable for foreign key
> purposes.) That has a hard time scaling in cases where nodes are
> over-connected, which is, broadly speaking, an acceptable sort of scenario.
Yes, that one attribute can be the adjacency set of adjacency lists.
For efficient access, we can store pointers to adjacency lists in hash
maps,with node identifier as keys(maybe).
Regards,
Atri
--
Regards,
Atri
l'apprenant