CALIBRE works with large government customers, including the U.S. Army, where maintenance, operation and support costs of equipment (depending on the program and program longevity) represent as much as 80 percent of total lifecycle costs and a single tank has about 10 million parts to track.
In this week’s five-minute interview (conducted at GraphTour DC) we discuss how CALIBRE has replaced recursive SQL queries with Neo4j, and is now able to train analysts right alongside developers.
Talk to us about how you use Neo4j at CALIBRE.
Preston Hendrickson: One of our customers asked us to do deep dive into parts and ordering. For example, say you have a chair. That chair has legs, a back, a seat and armrests. And some of those parts are interchangeable. We need to know which parts can also fit on other chairs. With that information, we can build chairs, swap parts out and so forth.
Why did you choose Neo4j for the project?
Hendrickson: We chose Neo4j because it allows us to take those parts and actually go down as many levels as required. Chairs are a minor example; it could be a car. In a car, you have hundreds or thousands of parts, and we need to know what interchangeable parts there are across models and across different vendors, like an auto parts store.
In cases like this, Neo4j becomes the better candidate so that we don’t have to write recursive SQL or dynamic SQL. We just write queries for Neo4j and traverse as many levels as we want and trace relationships, which is a lot faster than writing code or querying a database.
Can you talk to me about some of your most interesting or surprising results you had while using Neo4j?
Hendrickson: The number one thing we’ve found is how easy it is to teach people to use Neo4j. Anytime you change technology, the first thing you do is sit people in a room and train them to death – death by PowerPoint. Neo4j was mainly hands-on training.
We actually had not only developers and others with strong, high-tech skills, we had people across the gamut. We included anyone who was new to the company. We had analysts in the room who were able to pick up Neo4j in the exact same way that developers did.
Now we’re all in one accord, and we can all share the graph database.
If you could start over with Neo4j, taking everything you know now, what would you do differently?
Hendrickson: The first thing I would do is, before touching it, I would try to train my brain and not think about it like a traditional RDBMS. It took me a couple of weeks to figure out that I should not model like a traditional database, with third normal form and all that stuff.
I did not get that message until well into the 34th time rebuilding a graph. I tried to do it that way. If I had to start over, I’d work on understanding of what NoSQL, no-schema means versus building hands-on like I’m used to.
What do you see as the future of graphs in your projects?
Hendrickson: In our area, instead of just data retrieval, we want to move more into data science. We are looking into using Python a lot more to connect to the database directly versus taking data, exporting it into something else, having Python read it, getting answers, and pushing data back in. We’re trying to integrate those processes.
Anything else you want to add or say?
Hendrickson: This is exciting for us. It is a new area, and we’re trying to get more of our analytical teams more involved. At the same time, other people are watching those using Neo4j, and they’ve been getting more questions, and it spreads. We like it. We’re having a ball here.
Want to share about your Neo4j project in a future 5-Minute Interview? Drop us a line at firstname.lastname@example.org
Want to learn more on how relational databases compare to their graph counterparts? Get The Definitive Guide to Graph Databases for the RDBMS Developer, and discover when and how to use graphs in conjunction with your relational database.
Get the Ebook
Get the Ebook