NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



InfoGrid: Graph Database Schema

While most of the graph databases can be seen as collections of vertices and edges[1] carrying bags of properties, InfoGrid thinks that having some sort of a schema is good for both data integrity, code simplicity, and documentation purposes:

InfoGrid distinguishes between properties that must have a non-null value, and properties that may or or may not be null.


If InfoGrid did not distinguish between required and optional values, application code would be littered with unnecessary tests for null values. (or failing that, unexpected NullPointerExceptions.) We think being specific is better when creating the model; higher-quality and less cluttered application code is the reward.

InfoGrid is not alone, as we’ve seen a similar approach in the Java Content Repository node type definitions and also in OrientDB schema-less, schema-full, and mixed schema.

So what other creators think about schemas on graph databases?

  1. Check Marko A. Rodrigues and Peter Neubauer’s paper: Constructions from dots and lines  ()

Original title and link for this post: InfoGrid: Graph Database Schema (published on the NoSQL blog: myNoSQL)