I have tried personally Relational DB's a great deal and made the decision to go out on other forms available.

This specific product looks good and promising: http://neo4j.org/

Has anybody used graph-based databases? Do you know the benefits and drawbacks from the usability prespective?

Perhaps you have used these inside a production atmosphere? That which was the necessity that motivated you to employ them?

I made use of a graph database inside a previous job. We were not using neo4j, it had been an in-house factor built on the top of Berkeley DB, however it was similar. It had been utilized in production (situation).

The main reason we used a graph database could be that the data being saved through the system and also the procedures the machine was doing using the data were precisely the weak place of relational databases and were precisely the strong place of graph databases. The machine required to store collections of objects that lack a set schema and therefore are linked together by associations. To reason concerning the data, the machine required to perform a large amount of procedures that might be a few traversals inside a graph database, but that might be quite complex queries in SQL.

The primary the best-selling graph model were rapid development some time and versatility. We're able to rapidly add new functionality without affecting existing deployments. If your possible client desired to import a few of their own data and graft it on the top in our model, it might usually be achieved on-site through the sales repetition. Versatility also assisted whenever we were creating a brand new feature, saving us from attempting to squeeze new data right into a rigid data model.

Getting a strange database let's build lots of our other strange technologies, giving us plenty of secret-sauce to tell apart our product from individuals in our rivals.

The primary disadvantage was that people were not while using standard relational database technology, which can generate problems whenever your clients are enterprisey. Our clients would request why we could not just host our data on their own giant Oracle groupings (our clients usually had large datacenters). Among the team really rewrote the database layer to make use of Oracle (or PostgreSQL, or MySQL), however it was slightly reduced compared to original. A minumum of one large enterprise even had an Oracle-only policy, but fortunately Oracle bought Berkeley DB. We needed to write procuring tools - we could not only use Very Reviews for instance.

Another drawback to our graph database was that people built it ourselves, which meant whenever we hit an issue (usually with scalability) we needed to solve it ourselves. If we'd used a relational database, the seller might have already reduced the problem 10 years ago.

If you are creating a product for enterprisey clients as well as your data suits the relational model, make use of a relational database if you're able to. In case your application does not fit the relational model however it does fit the graph model, make use of a graph database. Whether it only fits another thing, use that.

In case your application does not have to squeeze into the present blub architecture, make use of a graph database, or CouchDB, or BigTable, or whatever fits your application and also you think is awesome. It could provide you with a benefit, and it is fun to test something totally new.

Anything you chose, do not build the database engine yourself unless of course you actually like building database engines.

We have been dealing with the Neo team for more than a year now and also have been happy. We model scholarly items as well as their associations, that is just right for any graph db, and run recommendation calculations within the network.

If you're already employed in Java, I believe that modeling using Neo4j is extremely easy and contains the flattest / quickest performance for R/W associated with a other solutions we attempted.

To tell the truth, I've got a difficult time not thinking when it comes to a Graph/Network since it is a lot simpler than creating convoluted table structures to keep object qualities and associations.

That being stated, we all do store some good info in MySQL due to the fact it's simpler for that Business side to operate quick SQL queries against. To do exactly the same functions with Neo we will have to write code that people simply not have the bandwidth for at this time. The moment we all do though, I am moving everything data to Neo!

Best of luck.