Re^2: Managing a graph with large number of nodes

Depending on the nature of the nodes and how they're going to be accessed/manipulated, an object store (such as Pixie, Tangram, or KiokuDB) seems likely to work well for something like this, while avoiding the need to worry about SQL schemas (even if the objects are ultimately stored into an SQL database).

Comment on Re^2: Managing a graph with large number of nodes

Replies are listed 'Best First'.
Re^3: Managing a graph with large number of nodes by Jenda (Abbot) on Nov 02, 2009 at 16:49 UTC
Well, in this case it seems that the whole schema will be just two tables `CREATE TABLE dbo.Users ( Id int not null identity(1,1) primary key, Code varchar(...), FirstAttribute ..., SecondAttribute ..., ... )go CREATE INDEX idx_Users_Code ON dbo.Users(Code) go CREATE TABLE dbo.Links ( UserId1 int not null, UserId2 int not null, Weight ..., CONSTRAINT pk_Links PRIMARY KEY CLUSTERED (UserId1, UserId2) )go` [download] and that's about it. Object store is most likely an overcomplication in this case. Jenda Enoch was right! Enjoy the last years of Rome.	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: Managing a graph with large number of nodes
by Jenda (Abbot) on Nov 02, 2009 at 16:49 UTC

Well, in this case it seems that the whole schema will be just two tables

CREATE TABLE dbo.Users (
  Id int not null identity(1,1) primary key,
  Code varchar(...),
  FirstAttribute ...,
  SecondAttribute ...,
  ...
)go
CREATE INDEX idx_Users_Code ON dbo.Users(Code)
go

CREATE TABLE dbo.Links (
  UserId1 int not null,
  UserId2 int not null,
  Weight ...,
  CONSTRAINT pk_Links PRIMARY KEY CLUSTERED (UserId1, UserId2)
)go
[download]

Object store is most likely an overcomplication in this case.

Jenda
Enoch was right!
Enjoy the last years of Rome.

[reply]
[d/l]