graph network structure with relational DB

I have a quite standard graph represention of a social network :
an auto-referential 'users' table (user_id , data...) and a
'relationship' join table (from_id, to_id)

is there any place to look for information about queries performance
(and related tricks or suggestions) when managing such kind of related
info , like 'find/count all related people to someone... up to a-level"
I read some interessing articles , but all are very academical ,
math-oriented, far from DB structure...

thanks for your advices

joss

I have looked at doing large relational databases for a couple ideas
that I have had for some social network style projects, but never could
fully come to a method that I would be happy with.

Since DB's have a one to one, one to many, and many to one relation
that would be just about all we could work with.

With social networking theory you break them in groups, nodes,
branches, and hubs. That said you would have to have a raw database
with each users one to one relation(s). From that you could query your
entire DB to find groups, and hubs then build a 2nd DB with these
hubs/groups and their members (Nodes I think).

That way you could say something in the effect of person/item (a) is
part of or has a one to one relation to (x) hub/group, and person (b)
has one relation to (z) hub/group, and group (z) is connected to group
(x), by group (c)>(d)>(m).

Thus you would only have to find the two users closes hub(s) and then
query the database step by step to the next hub(less queries).

Mapping logic... If anyone else has any information on the subject I
would also like to hear what they have to say on it.

On 2007-01-13 18:41:02 +0100, "l3vi" <admin@madfrogproductions.com> said:

> I have looked at doing large relational databases for a couple ideas
> that I have had for some social network style projects, but never could
> fully come to a method that I would be happy with.
>
> Since DB's have a one to one, one to many, and many to one relation
> that would be just about all we could work with.
>
> With social networking theory you break them in groups, nodes,
> branches, and hubs. That said you would have to have a raw database
> with each users one to one relation(s). From that you could query your
> entire DB to find groups, and hubs then build a 2nd DB with these
> hubs/groups and their members (Nodes I think).
>
> That way you could say something in the effect of person/item (a) is
> part of or has a one to one relation to (x) hub/group, and person (b)
> has one relation to (z) hub/group, and group (z) is connected to group
> (x), by group (c)>(d)>(m).
>
> Thus you would only have to find the two users closes hub(s) and then
> query the database step by step to the next hub(less queries).
>
> Mapping logic... If anyone else has any information on the subject I
> would also like to hear what they have to say on it.

thanks a lot for your feedback... right now I'll work on 2 levels only
, and doing simple queries

a user A has 1st level relationship (let's say 30 other users)
at 2nd level this 30 people may also have their own 1st level
relationship, which gives A a second level relationship of 900 users..
that's all for now... I'll write the methods to handle that

I read an article (pdf) "Using Structure Indices for Efficient
Approximation of Network Properties" written by Matthew J. Rattigan
(rattigan@cs.umass.edu), Marc Maier (maier@cs.umass.edu) and David
Jensen (jensen@cs.umass.edu) which is very interesting on the subject...

joss

On 15.01.2007 12:49, Josselin wrote:
> thanks a lot for your feedback... right now I'll work on 2 levels only
> , and doing simple queries
>
> a user A has 1st level relationship (let's say 30 other users)
> at 2nd level this 30 people may also have their own 1st level
> relationship, which gives A a second level relationship of 900 users..
> that's all for now... I'll write the methods to handle that

You can deal with fixed level of nesting queries in a single SELECT
statement - SQL just chokes on the unlimited recursion (unless you are
on Oracle and can use CONNECT BY).

Kind regards

robert

On 2007-01-15 13:12:55 +0100, Robert Klemme <shortcutter@googlemail.com> said:

> On 15.01.2007 12:49, Josselin wrote:
>> thanks a lot for your feedback... right now I'll work on 2 levels only
>> , and doing simple queries
>>
>> a user A has 1st level relationship (let's say 30 other users)
>> at 2nd level this 30 people may also have their own 1st level
>> relationship, which gives A a second level relationship of 900 users..
>> that's all for now... I'll write the methods to handle that
>
> You can deal with fixed level of nesting queries in a single SELECT
> statement - SQL just chokes on the unlimited recursion (unless you are
> on Oracle and can use CONNECT BY).
>
> Kind regards
>
> robert

thanks a lot, I'll
joss