Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I think you have to consider that the non-relational DBMS differ a lot regarding their data model and therefore the conceptual data design will also differ a lot. In the thread <a href="http://groups.google.com/group/nosql-discussion/browse_thread/thread/bbe3aa69071fd7b9/b5bb363c32f598c9" rel="nofollow noreferrer">Data Design in Non-Relational Databases</a> of the <a href="http://groups.google.com/group/nosql-discussion/" rel="nofollow noreferrer">NOSQL Google group</a> the different paradigms are categorized like this:</p> <ol> <li>Bigtable-like systems (HBase, Hypertable, etc)</li> <li>Key-value stores (Tokyo, Voldemort, etc)</li> <li>Document databases (CouchDB, MongoDB, etc)</li> <li>Graph databases (AllegroGraph, Neo4j, Sesame, etc)</li> </ol> <p>I'm mostly into <a href="https://stackoverflow.com/questions/1000162/have-anyone-used-graph-based-databases-http-neo4j-org">graph databases</a>, and the elegance of data design using this paradigm was what brought me there, tired of the shortcomings of <a href="http://en.wikipedia.org/wiki/Relational_database_management_system" rel="nofollow noreferrer">RDBMS</a>. I have put a few examples of data design using a graph database on this <a href="http://wiki.neo4j.org/content/Domain_Modeling_Gallery" rel="nofollow noreferrer">wiki page</a> and there's an <a href="http://wiki.neo4j.org/content/IMDB_The_Domain" rel="nofollow noreferrer">example of how to model</a> the basic <a href="http://en.wikipedia.org/wiki/Internet_Movie_Database" rel="nofollow noreferrer">IMDB</a> movie/actor/role data too.</p> <p>The presentation slides (slideshare) <a href="http://www.slideshare.net/adorepump/graph-databases-and-the-future-of-largescale-knowledge-management" rel="nofollow noreferrer">Graph Databases and the Future of Large-Scale Knowledge Management</a> by <a href="http://markorodriguez.com/" rel="nofollow noreferrer">Marko Rodriguez</a> contains a very nice introduction to data design using a graph database as well.</p> <p><em>Answering the specific questions from a graphdb point of view:</em></p> <p>Alternate design: adding relationships between many different kinds of entities without any worries or a need to predefine which entities can get connected.</p> <p>Bridging the gap: I tend to do this different for every case, based on the domain itself, as I don't want a "table-oriented graph" and the like. However, <a href="http://wiki.neo4j.org/content/SQL_Importer" rel="nofollow noreferrer">here's</a> some information on automatic translation from RDBMS to graphdb.</p> <p>Explicit data models: I do these all the time (whiteboard style), and then use the model as it is in the DB as well.</p> <p>Miss from RDBMS world: easy ways to create reports. Update: maybe it's not <em>that</em> hard to create reports from a graph database, see <a href="http://www.reportsanywhere.com/pebble/2010/05/30/creating_a_report_for_a_neo4j_sample_database.html" rel="nofollow noreferrer">Creating a Report for a Neo4J Sample Database</a>.</p>
 

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