Using a database is commonplace for most any type of software application you build. The data generated using the application has to be stored some place. However, when it comes down to it, a presumption is typically made that the database is going to be a Relational Database and the developers are probably going to use some type of Object Relational Mapping (ORM) tool to make the job of dealing with the database easier. I propose that this traditional enterprise application building activity be placed on hold in favor of re-thinking the use of the go to database type.

Now, I am not stating that we should entirely forgo the use of a SQL Database. In fact, the tooling support for relational database is so rich and the existing talent pool in the Business Intelligence (BI) space is filled with professionals having mastered the use of such tools. Instead, I propose that you re-think the way your data is modeled. Over the last couple of years, I have had the privilege to work on several projects and proof-of-concepts that make use of the leading Graph Database -- Neo4j -- that it has expanded my view to where I can state that many problem domains can be, and perhaps should be, mapped as a graph.

Consider the case of an inventory tracking system in the Retail industry. To build one from the ground-up, we can begin by mapping the base attributes of a product and the various product types that will be supported. Initially, we don't know all the attributes because we don't know all the suppliers that will make up the inventory stocked. Then, we want to track related products that compliment one another. We can't map all the relationships because we may not know all the details about all the products that will be stocked. There is also a logistical challenge whereby we cannot possibly know all the products if we are to carry thousands of them. Then comes the online sale of the products, user reviews attached to the products, and so on and so forth. I think you get the idea.

In a Graph Database, mapping all these relationships and attributes would be far more intuitive. Let's examine the following sample graph:

As you can see, the detail of the relationships between the nodes (circles in the graph) quickly suggests to the reader how two domain entities are related to one another. Furthermore, we can intuitively add and change the schema as the business grows or as the needs of the stakeholders grow. Application developers will quickly recognize the complexity that is avoided if a SQL database is replaced in favor of a Graph Database. Each node may have any number of properties to describe its attributes. Additionally, each relationship can carry attributes describing the As you need more attributes, just add and don't worry about schema migrations. Need more nodes, just add and don't worry about migrations.

Imagine creating all those Foreign Keys and queries to later retrieve the related data from a SQL database. Then deciding if we should use Stored Procedures to optimize certain parts of the application or just put all the code inside the application. All that is simplified with a solution such as Neo4j. So, what does the switch to a Graph Database like Neo4j get a business? Here is a short list:

• Rapid application development
• Real-time business intelligence
• Immediate scalability as the demand on the data increases
• Cloud hosting in Azure or AWS
• Cross-platform data access

I will continue this topic with some deep dives on how to setup a Neo4j cluster in Azure for failover and for High Availability. Furthermore, I will discuss how you can set it up such that you an optimize the cluster for when your application is write-heavy, read-heavy, or both. I hope you too realize the benefits and efficiencies gained with a Graph Database.