Showing posts with label Graph Databases. Show all posts
Showing posts with label Graph Databases. Show all posts

Friday, February 17, 2017

Graph databases and rapid prototyping (part 3)

In this last part, I am comparing the development experiences when using SQL Server and Neo4j graph database. There is also an overview of Neo4j tools and functionality, and how they accelerate web development and prototyping.

Part 1: How I got hooked on graph databases
Part 2: What is a graph database
Part 3: Rapid prototyping
"Java and Javascript are similar like Car and Carpet are similar" - fun fact
Now when I think about it, a graph database feels like a dynamically-typed language, and a SQL database - like a statically-typed one. As you would consider a dynamically-typed language, such as JavaScript, for the web development and prototyping, a graph database is also a good option for these cases.

"If all you have is a hammer, everything looks like a nail" - the law of the instrument
We have successfully used SQL Server on many projects, and it was our default database choice. For our recent web application, it required a good amount of design and plumbing before we can expose data through Web API. As requirements refined, our initial design underwent many changes. Even with good tools and automated steps, it was painful and time-consuming making changes to the data schema, and, despite 2 abstraction layers, the app was often broken afterwards.

Thursday, February 9, 2017

Graph databases and rapid prototyping (part 2)

In this part, I am providing a brief explanation of what a graph database is, with some examples on the data modeling and querying. I am also talking about the schema-less nature of the graph databases, and what advantages it provides when you just start your project.

Part 1: How I got hooked on graph databases
Part 2: What is a graph database
Part 3: Rapid prototyping
"Fool tidies up, a genius rules over chaos" - Albert Einstein

A graph database looks like a bunch of nodes with properties (key-value pairs) and relationships between them. Imagine you gathered data from multiple sources about people, their tweets, posts, likes, friend and followers. Each node may have some unique properties, and there could be similarities.
Rihanna is a friend with the monster, and she likes his posts
Similar nodes can be categorized using labels, such as "person", "monster" and "post". Relationships can have labels too, like "friend", "likes" and "publishes".

Tuesday, February 7, 2017

Graph databases and rapid prototyping (part 1)

In the first part, I'll tell you how I was forced out my comfort zone (SQL Server), and look for alternatives in the graph database space. I choose Neo4j, and I was surprised how easy it was to use, and how productive I became.

Part 1: How I got hooked on graph databases
Part 2: What is a graph database
Part 3: Rapid prototyping

I am very excited to share tremendous experience I had with graph databases (Neo4j specifically), and how going schema-less first (and hybrid or schema-full later) changed my approach to design software. This topic is orthogonal to "NoSQL", the term that holds the second place ("cloud" being the first) in overuse and ambiguity.

For many years, my "to go" (and only) option to do any database work was Microsoft SQL Server. It was easy and natural to open Management Studio and start writing SQL queries. Plus, vast and mature tooling, integration options, language support, community and documentation... you name it.