Prev: php array in different OS
Next: Extending Exception
From: Tim Gallagher on 21 Jul 2010 11:04
I cannot be the only one that is having this problem, what are you using for DAG (Direct Acrylic Graph)? I need to have a mesh node edge graph and am having trouble with this? I see that Neo4j has a rest server and I can do this in Java but I want to do it in PHP with a MYSQL or postgresql. If you are doing something like this, can you please tell me how you are doing this. I can do a relationship with a parent child or a nested tree, but I need to do a DAG.

Thanks for the help,
timgerr
From: Andrew Ballard on 21 Jul 2010 11:40
On Wed, Jul 21, 2010 at 11:04 AM, Tim Gallagher <tgallagher(a)danati.com> wrote:
> I cannot be the only one that is having this problem, what are you using for DAG (Direct Acrylic Graph)?  I need to have a mesh node edge graph and am having trouble with this?  I see that Neo4j has a rest server and I can do this in Java but I want to do it in PHP with a MYSQL or postgresql.  If you are doing something like this, can you please tell me how you are doing this.  I can do a relationship with a parent child or a nested tree, but I need to do a DAG.
>
> Thanks for the help,
> timgerr
>

A basic approach would be to use two tables - one to store the nodes
and second table to store the edges between the nodes. As far as
traversing the graph, the best approach I have seen expands this a bit
to store the full transitive closure of the graph, rather than just
the direct edges:

http://www.codeproject.com/KB/database/Modeling_DAGs_on_SQL_DBs.aspx

It is written for SQL Server, but the idea works OK (and I
successfully tested it once) in MySQL. (I imagine the same would be
true for PostgreSQL.)

The idea is to store the transitive closure (every possible path) of
the entire graph. For instance, if you have a basic graph

A -> B -> C -> D

it stores these paths:

A -> B
B -> C
C -> D
A -> C
B -> D
A -> D

The obvious downside is that edge table can get incredibly large
depending on the nature of the graph you are modeling. (The article
provides much more detail.) I did, however, import a good chunk of an
Active Directory tree (just users and groups, not the full list of
attributes) into this pattern just to test the concept, and I found
that in that case the size of the transitive closure table did not get
out of hand.


Andrew
From: Tim Gallagher on 21 Jul 2010 15:49
Thank you for the informaiton. I did see that code but it looks like it is formatted for MSSQL and was unable to get it to work for Mysql.

Tim

________________________________________
From: Andrew Ballard [aballard(a)gmail.com]
Sent: Wednesday, July 21, 2010 11:40 AM
To: Tim Gallagher
Cc: php-general(a)lists.php.net
Subject: Re: [PHP] Question about SQL and Graph nodel trees

On Wed, Jul 21, 2010 at 11:04 AM, Tim Gallagher <tgallagher(a)danati.com> wrote:
> I cannot be the only one that is having this problem, what are you using for DAG (Direct Acrylic Graph)? I need to have a mesh node edge graph and am having trouble with this? I see that Neo4j has a rest server and I can do this in Java but I want to do it in PHP with a MYSQL or postgresql. If you are doing something like this, can you please tell me how you are doing this. I can do a relationship with a parent child or a nested tree, but I need to do a DAG.
>
> Thanks for the help,
> timgerr
>

A basic approach would be to use two tables - one to store the nodes
and second table to store the edges between the nodes. As far as
traversing the graph, the best approach I have seen expands this a bit
to store the full transitive closure of the graph, rather than just
the direct edges:

http://www.codeproject.com/KB/database/Modeling_DAGs_on_SQL_DBs.aspx

It is written for SQL Server, but the idea works OK (and I
successfully tested it once) in MySQL. (I imagine the same would be
true for PostgreSQL.)

The idea is to store the transitive closure (every possible path) of
the entire graph. For instance, if you have a basic graph

A -> B -> C -> D

it stores these paths:

A -> B
B -> C
C -> D
A -> C
B -> D
A -> D

The obvious downside is that edge table can get incredibly large
depending on the nature of the graph you are modeling. (The article
provides much more detail.) I did, however, import a good chunk of an
Active Directory tree (just users and groups, not the full list of
attributes) into this pattern just to test the concept, and I found
that in that case the size of the transitive closure table did not get
out of hand.


Andrew
From: "Tommy Pham" on 22 Jul 2010 06:29

> -----Original Message-----
> From: Tim Gallagher [mailto:tgallagher(a)danati.com]
> Sent: Wednesday, July 21, 2010 12:49 PM
> To: Andrew Ballard
> Cc: php-general(a)lists.php.net
> Subject: RE: [PHP] Question about SQL and Graph nodel trees
>
> Thank you for the informaiton. I did see that code but it looks like it is
> formatted for MSSQL and was unable to get it to work for Mysql.
>
> Tim
>

@Tim, You'll have to migrate the stored procedures (SP) from MSSQL to MySQL (aka stored programs). Each DBMS have their own way of implementing the SP.
http://dev.mysql.com/doc/refman/5.1/en/stored-programs-views.html

@Andrew, interesting link! Thanks!

Regards,
Tommy

> ________________________________________
> From: Andrew Ballard [aballard(a)gmail.com]
> Sent: Wednesday, July 21, 2010 11:40 AM
> To: Tim Gallagher
> Cc: php-general(a)lists.php.net
> Subject: Re: [PHP] Question about SQL and Graph nodel trees
>
> On Wed, Jul 21, 2010 at 11:04 AM, Tim Gallagher <tgallagher(a)danati.com>
> wrote:
> > I cannot be the only one that is having this problem, what are you using for
> DAG (Direct Acrylic Graph)? I need to have a mesh node edge graph and am
> having trouble with this? I see that Neo4j has a rest server and I can do this
> in Java but I want to do it in PHP with a MYSQL or postgresql. If you are doing
> something like this, can you please tell me how you are doing this. I can do a
> relationship with a parent child or a nested tree, but I need to do a DAG.
> >
> > Thanks for the help,
> > timgerr
> >


>
> A basic approach would be to use two tables - one to store the nodes and
> second table to store the edges between the nodes. As far as traversing the
> graph, the best approach I have seen expands this a bit to store the full
> transitive closure of the graph, rather than just the direct edges:
>
> http://www.codeproject.com/KB/database/Modeling_DAGs_on_SQL_DBs.a
> spx
>
> It is written for SQL Server, but the idea works OK (and I successfully tested it
> once) in MySQL. (I imagine the same would be true for PostgreSQL.)
>
> The idea is to store the transitive closure (every possible path) of the entire
> graph. For instance, if you have a basic graph
>
> A -> B -> C -> D
>
> it stores these paths:
>
> A -> B
> B -> C
> C -> D
> A -> C
> B -> D
> A -> D
>
> The obvious downside is that edge table can get incredibly large depending
> on the nature of the graph you are modeling. (The article provides much
> more detail.) I did, however, import a good chunk of an Active Directory tree
> (just users and groups, not the full list of
> attributes) into this pattern just to test the concept, and I found that in that
> case the size of the transitive closure table did not get out of hand.
>
>
> Andrew
> --
> PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
> http://www.php.net/unsub.php


 | 
Pages: 1
Prev: php array in different OS
Next: Extending Exception