The other day I was thinking back to the days when I worked in custom application development. I asked myself a question: what was the biggest bottleneck that slowed your projects down? After having a wonderful conversation with myself I began asking my friends the same question. The overwhelming answer has been simple, the database. Systems don’t work without data, so what choice did we have? We had to embrace, or at least accept, the time it took to setup and maintain the database as part of the overall project timeline. Typically, I only worked with the common SQL databases. I did one internship where we worked with a NoSQL database and very quickly decided that I didn’t want to work with them. Why? Because if you think there’s too much overhead with a SQL database, just try working with a NoSQL database. I was always a fan of having some sort of data model, but not necessarily one that crippled development, which is what I found myself with more often than not.  

In past projects my team and I have been heavily dependent on DBAs to design, implement, and maintain the database. We’ve used ORM frameworks like Hibernate, to connect our application and the database. What would happen more often than not is that we, the development team, would require a change made to the data model. We would make the change on the application side and put in a request to the DBA team. Fast teams were able to complete this within a couple of hours, slow teams took a few days. In the mean time, we were essentially blocked from testing our application because the application and the database were out of sync. Needless to say, this significantly slowed down development velocity, which in turn cost my clients’ money. 

The other issue we found ourselves running into was database constraints. While I like the concept of foreign keys, they rapidly became a hindrance. Our application ensured relationships between entities stayed intact. However, if we wrote two entities to the database in the wrong order, or even at the same time, we would get all kinds of constraint errors. This was the case when things were configured correctly, however, quite often we find ourselves with criss-crossed constraints. I will always advocate for maintaining relationships, but I don’t think it has to be done in multiple places. Leaving it up to the application itself is significantly easier from a development perspective with little to no performance difference. Once again, this slowed down development velocity, in turn costing my clients’ money.  You may have seen our tag line, “Simplicity Without Sacrifice.” We believe that the database shouldn’t handcuff development, but instead it should enable it. That’s why we built a database that can handle SQL or NoSQL. Just the other day I was building a simple demo application for our booth at IoT World, more on that coming in future blog posts, it certainly wasn’t the most complicated data model in the world, but I still figured it would take me a few hours to setup. In the end, it took me about 20 minutes. Schemaless SQL makes database inserts a breeze. I didn’t need to create table structures, primary keys, foreign keys, indexes, or any of the other typical database artifacts. Instead, I created the table, wrote my INSERT statement, and HarperDB did the rest of the work for me. I start with SQL, because that’s what I’m more comfortable with, but this was a demo application after all, so I swapped over to full NoSQL CRUD for the next phase of the project. 

Now, in full disclosure, I don’t have a ton of experience with NoSQL. Like I said, I thought it was overly complex and inefficient. As I’ve recently discovered, it’s not NoSQL that I didn’t like, but the underlying databases. The more I develop with NoSQL, the more I like it. It’s a simple JSON structure, simply and exactly describing the full NoSQL CRUD operation I’d like to execute. The point I’m trying to illustrate here is that HarperDB empowers the developer to build and maintain data relationships. We provide flexibility for developers to choose their favorite languages. The major lift in application development should be the application itself, not the underlying foundations. Go download our Community Edition and see just how easy it is to get your application database up and running!