----- Цитат от Christopher Browne (cbbro...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
