----- Цитат от Christopher Browne (cbbrowne@gmail.com), на 29.04.2013 в 23:18 -----
>
> 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.
> ...
Hello,
From the start of the discussion I was trying to get what this graph
data type should be... I could not grasp it.
With the current postgres, in the most simple case we could do something
like:
create table node ( node_id serial primary key, ...
);
create table edge( from integer references node, to integer[] -- each element references node
);
With the addition of foreign keys constraint on arrays elements (that I
understand is work in progress), we could guarantee referential
integrity of the graph - I really hope that it will be ready for 9.4.
Without the array elements foreign keys constraints, if we have to
guarantee the integrity we could do:
create table edge( from integer referecens node, to integer references node, weight real, ...
);
What is missing are some algorithms. I have personaly implemented some
algorithms using recursive queries and it is doable (most of my
experience was with Oracle but lately I have put in production some
postgresql schemas with recursive queries that are working just fine).
For large scale eigen values factorisation (think pagerank) this
sparse matrix form is reasonable data organisation (though I have
doubts that the best place to run this job is in the database)
Best regards
luben
