Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You didn't give us enough information to respond with a well thought out answer. For example: what size are these graphs? With what frequencies do you expect to query these graphs? Do you need real-time response to these queries? More information on what your application is for, what is your purpose, will be helpful.</p> <p>Anyway, to counter the usual responses that suppose SQL-based DBMSes are unable to handle graphs structures effectively, I will give some references:</p> <p> <li><a href="http://tfs.cs.tu-berlin.de/grabats/Final04/varro.pdf" rel="nofollow noreferrer">Graph Transformation in Relational Databases</a> (.pdf), by G. Varro, K. Friedl, D. Varro, presented at <a href="http://tfs.cs.tu-berlin.de/grabats/GraBaTs%2704%20Programme.html" rel="nofollow noreferrer">International Workshop on Graph-Based Tools (GraBaTs) 2004</a>;</p> <blockquote> <b>5 Conclusion and Future Work</b> <br><br> In the paper, we proposed a new graph transformation engine based on off-the-shelf relational databases. After sketching the main concepts of our approach, we carried out several test cases to evaluate our prototype implementation by comparing it to the transformation engines of the AGG [5] and PROGRES [18] tools. <br> The main conclusion that can be drawn from our experiments is that relational databases provide a promising candidate as an implementation framework for graph transformation engines. We call attention to the fact that our promising experimental results were obtained using a worst-case assessment method i.e. by recalculating the views of the next rule to be applied from scratch which is still highly inefficient, especially, for model transformations with a large number of independent matches of the same rule. ... </blockquote> <p>They used <a href="http://www.postgresql.org/" rel="nofollow noreferrer">PostgreSQL</a> as DBMS, which is probably not particularly good at this kind of applications. You can try <a href="http://www.luciddb.org/" rel="nofollow noreferrer">LucidDB</a> and see if it is better, as I suspect. </li><li><a href="http://www.comp.nus.edu.sg/~wongls/projects/ies-sql/index.html" rel="nofollow noreferrer">Incremental SQL Queries</a> (more than one paper here, you should concentrate on " <em>Maintaining Transitive Closure of Graphs in SQL</em> "): "</p> <blockquote>.. we showed that transitive closure, alternating paths, same generation, and other recursive queries, can be maintained in SQL if some auxiliary relations are allowed. In fact, they can all be maintained using at most auxiliary relations of arity 2. .. </blockquote> <p></li><li><a href="http://aehrc.com/pubs/papers/abstract/RP-CP-GD-KR-incr-maint-short-dist-trans-clos-logic-sql.htm" rel="nofollow noreferrer">Incremental Maintenance of Shortest Distance and Transitive Closure in First Order Logic and SQL</a>. </li></p> <p><br> <strong>Edit:</strong> you give more details so... I think the best way is to experiment a little with both a main-memory dedicated graph library and with a DBMS-based solution, then evaluate carefully pros and cons of both solutions.</p> <p>For example: a DBMS need to be installed (if you don't use an "embeddable" DBMS like <a href="http://sqlite.org/" rel="nofollow noreferrer">SQLite</a>), only you know if/where your application needs to be deployed and what your users are. On the other hand, a DBMS gives you immediate benefits, like persistence (I don't know what support graph libraries gives for persisting their graphs), transactions management and countless other. Are these relevant for your application? Again, only you know.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload