Microsoft GraphView: Use SQL Server or Azure SQL to efficiently manage graphs

Re:Microsoft GraphView: Use SQL Server or Azure SQL to effic... by yid on Tuesday December 22, 2015 @01:28AM (#10776209)

Seems like its more geared towards matching relatively small template-based subgraph patterns rather than doing arbitrary walks efficiently. From page 9 of the user manual:

> Below is an example query matching a triangle over the employee-client graph:

    SELECT En1.Name, En2.Name, Cn.Name
    FROM EmployeeNode AS En1, EmployeeNode AS En2, ClientNode AS Cn
    MATCH En1-[Colleagues AS Cg]->En2-[Clients AS C1]->Cn,
          En1-[Clients AS C2]->Cn
    WHERE En1.Name = ‘Jane Doe’ AND C1.credit > 1000

[ Parent | on HN ]

Re:Microsoft GraphView: Use SQL Server or Azure SQL to effic... by pbnjay on Tuesday December 22, 2015 @09:35AM (#10777923)

Clearer and more standard SQL Join:

    SELECT En1.Name, En2.Name, Cn.Name
      FROM EmployeeNode AS En1, EmployeeNode AS En2, ClientNode AS Cn,
           Colleagues AS Cg, ClientOf AS C1, ClientOf AS C2
     WHERE En1.Name = ‘Jane Doe’ AND C1.credit > 1000
       AND En1.ID=Cg.ID1 AND En2.ID=Cg.ID2
       AND En1.ID=C1.EnID AND En2.ID=C2.EnID
       AND C1.CnID=C2.CnID

Really all the "MATCH" gets you is cleaner many-to-many join. But is that tradeoff worth the DLL dependency and burden to bringing on new developers?

[ Parent | on HN ]

Re:Microsoft GraphView: Use SQL Server or Azure SQL to effic... by Someone on Tuesday December 22, 2015 @02:47PM (#10779894)

http://research.microsoft.com/pubs/259290/GraphView%20User%2...:

  CREATE TABLE EmployeeNode
  (
    [ColumnRole:”NodeId”] 
    WorkId varchar(32),
    [ColumnRole:”Property”]
    Name varchar(32),
    [ColumnRole:”Edge”, Reference:”EmployeeNode”]
    Colleagues VARBINARY,
    [ColumnRole:”Edge”, Reference:”ClientNode”, Attributes: {credit:”int”, note:”string”}]
    Clients VARBINARY
  )

=> they also appear to replace "many rows each with key and a single referenced value" by "row for each unique key with packed values for that key" (possibly with multiple rows for a key if the packed data doesn't fit in a VARBINARY(MAX))

So, the database structure looks a bit like an inverse index. That could speed up some queries.

I have been playing with something similar in pure T-SQL, using a cross apply over a table-valued function to get from this packed format back to the normalized table, but wasn't impressed with its performance. Using CLR was next on my list, but I haven't come around it because I don't have high hopes that it will perform, but I may try this.

[ Parent | on HN ]