Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Development Tools >

What are graph databases good for? Here's a killer app

Take Neo4j for a test spin with a CRUD demo based on Granny's Addressbook

By Andrew C. Oliver, InfoWorld, 08/01/13

  • Print
  • Feedback

My fans know that my standard test for everything from PaaS (platform as a service) to alternative programming languages is something I call Granny's Addressbook, a simple CRUD application. As it turns out, Granny's Addressbook is also an excellent test for graph databases, the black sheep of the NoSQL quadrumvirate (see "Which freaking database should I use?"). To add functionality to the Addressbook, we've used the leading graph database: Neo4j. Thanks to Phil Rhodes for his contributions to this article and for writing my code for me so that I had more time to cozy up to a nice glass of Lagavulin, neat. -- Andy Oliver

My kids' paternal grandmother -- I call her "Mom" -- has a problem that is not solved by her killer app, Granny's Addressbook. Frequently, she asks me what gift to get the kids for the all-too-frequent stream of birthdays, Hanukkah, Christmas, Kwanzaa, Arbor Day, and whatever holidays. Frequently, I inform her that the children are already spoiled and I've gotten them anything they need and if not, there is a good reason that I don't want them to have it. Those reasons vary from "it's flammable" to "it's a weapon if you hold it right" to "it makes annoying noises that I don't want to hear" to the more common "I don't feel like figuring out how to assemble it and by the time it gets assembled the pieces will have been lost."

In other words, Grandma has a data problem. If she were to map out what all of the kids' friends or other children close to their age got for their birthday, she could easily figure out what to buy them without asking me.

As you recall, Grannny's Addressbook is a sample app I've used to demonstrate various technologies. It is essentially a one-table CRUD app that stores addresses in a database. It has no search or security and it doesn't really need to scale. The GUI looks like this:

In this case, the gift-giving problem has landed Granny in a complex data dilemma. She needs to know the kids' ages and their relationships to other people. She also needs to know what each kid got for his or her last birthday. We will represent this with three rather naive fields: First is "Friends," which is a multiselect list box. The second is "Birthday." The third is "Last Present," representing gifts from their most recent birthday. So long as those fields are populated, we'll populate another field called "Suggested Presents," which is a list of gift ideas. The new GUI looks like this:

We essentially want to recommend a gift for a person based on what each of friend and friends of friends got for their last birthday. We also want to order the gifts by the distance of the relationship.

For example: Tommy is friends with Billy and Bryan. Bryan is friends with Kelly and Jamie. Jamie is friends with Steven. Billy is friends with Keith. We can look at the "distance of the relationships" thusly:

Tommy = 0 (the origin)

Billy = 1

Bryan = 1

Kelly = 2

Jamie = 2

Keith = 2

Steven = 3

Doing this in a relational database structure is pretty painful. In the JPA/SQL version of granny, I need two tables and multiple trips to the database just to walk the graph of relationships. I also have to do pretty much all the ordering and logic myself.


For more enterprise computing news, visit InfoWorld. Story copyright InfoWorld Media Group, Inc.

  • Print
  • Feedback