Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

7 Ways the Right Database Pays for Itself

DZone's Guide to

7 Ways the Right Database Pays for Itself

Here's an overview of good features for a database to have, including ease-of-use, an intuitive GUI, dynamic querying capabilities, and solid scalability.

· Database Zone ·
Free Resource

RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.  

Operating deep inside your application, a good database should function like your heart:

  • You never see it.
  • You don’t know how it works, and you don’t need to know how it works – as long as it’s working.
  • In pumping blood to the entire body, it feeds the performance of every other part of your system. To keep the system at peak performance, it must be working all the time.
  • The better it works, the better every other part of your system works.

To reach this ideal state, you have to pay lots of money for a good cardiologist, a health and fitness instructor, and all the right foods to reach your body’s peak performance. The same with a database. To optimize all it can do for you, it will cost money.

But what if investing in the best database on the market returned you so much in cost savings and enhanced revenue it exceeded the price of the database? The right database should ultimately pay you huge dividends in function, performance, and productivity.

Here are the 7 must-haves the right database must offer to generate you a positive return on your next project

1. It Must be Easy to Learn

A developer earns on average, $140,000 a year to make an app that will impact the bottom line of a company by millions, even tens of millions of dollars in increased revenue, lower expenses, or a combination of both achieved by productivity gains.

Every moment he or she is not working to improve their app is a moment you are not getting the most on your investment. A database shouldn’t take too much time diverting a developer from their art by forcing them to relearn the alphabet in order to query the database.

The best databases are easy to learn, using an SQL based language that you can pick up fast.

Costly databases require companies to pay large amounts in the form of training sessions, and downtime for the developers to train their entire staff on how to use a database that is complicated to navigate. As you scale out, and developers in other offices worldwide will also have to go through the process of reading stereo instructions to see how the database works.

2. Easy to Set Up and Secure

One database requires you to understand a 60-page document on how to install and use their security. It’s no wonder they were hacked into over 100,000 times! It can take days, even weeks to install and secure a database. A setup wizard that can tackle this task in minutes. The best databases treat security as a baseline requirement, not something that your admin will tackle sometime down the road, and will include security in the setup wizard to make your initial steps as simple as possible

This saves your developers time, and you lots of worry. 

3. A GUI Anyone Can Use That Tells You What You Really Need to Know

A good GUI can increase the productivity of your Database Administrator by a good 25%. It will show CPU usage, which nodes on your cluster are functioning, which ones are down, and the recommended fixes needed. A lot of the functions DBA’s are used to doing manually, a good database can automate, giving you even more information to tackle potential problems before the cost to act on them becomes serious.

4. Easy to Scale

What happens when your application is a stunning success and everyone just has to have it on their device? You get more traffic, more users, and more data to manage.

You have to scale out your database. But at what cost? How much time will your IT team have to dedicate to scaling instead of focusing on your app right when it makes it to prime time?

A database should offer the ability to create a cluster with ease. You should be able to add additional nodes to a data cluster and replicate your database to each new node quickly so you can offer your users faster performance as the stadium of users to your app exceeds its capacity.

With a relational database, a good server can cost you $20,000.  Once your data storage and load has filled up, you need additional servers. A non-relational database uses commodity hardware costing less than $1,000.

5. Less Need for Technical Support

A good database is one that you don’t have to worry about, it just works. It should have diagnostic tools to always monitor what’s working, and what isn’t. If something goes down, or simply isn’t working optimally, you will be sent a notification with a recommended fix. The aim is to optimize the time you are in control of your application and can keep on developing it without interruption.

In those situations where you do need help, a good database provides should know that there is nothing more frustrating than handing the fate of your application over to a third party who may not share your sense of urgency. It needs to go beyond the letter of the SLA agreement by not only shooting out an automated “We got your issue and will reply shortly,” within 2 hours, but to actively work on fixing the problem right away. Every day that your developer has to wait, it can cost you $560, as the next release of your app remains stalled just short of the finish line.

You need dedicated access to the people who built the database who know the intimate details of, rather than someone with limited familiarity who forces you to jump through hoops while they walk you through the support scripts. This saves you time, money, and lots of frustration.

6. Speed Up Your Release Cycle

Changing the DB schema typically means taking down the application, maybe for hours. It will require an expert to go through all the queries your application makes, comparing them to the existing indexes and verifying that there hasn’t been any performance regression.

This forces your IT team to invest more hours into the new release while compromising your data network.

A schemaless database makes changes easy. Changes to the schema in a document database are less costly in developer resources needed and are less disruptive to the steady running of your application.

All of this shortens the time to your next release, enabling you to make that leap forward in revenue or cost savings that much sooner.

7. Dynamic Querying to Keep Your Process Agile

Distractions are momentum killers. Any type of downtime, freeze, or crash can turn away countless potential customers and keep them from buying. 1 in 4 shopping carts are abandoned before purchase – mostly due to performance. If the user has a few extra seconds to reconsider, especially while the payment page is taking its sweet time to load, they have more time to walk away.

One of the hidden dangers of an effective Agile Development process is that you are constantly tweaking the application. When you first create your application, you set up queries and indexes so when a user hits a button, the database knows exactly what to do in the most efficient manner. Peak performance becomes a given.

When you make a new version of your app, you change the way the application makes queries from the database. This can render your indexes obsolete, forcing the database to go over every piece of info it has, bit by bit, until it can answer the new queries of your latest build. This may kill performance every time you release a new version of your app.

You can avoid this mess with dynamic querying. When a query is made to find or aggregate data, the right database will check to see if there are indexes available to do it faster. If there aren’t, it will make one. Once done, it will see if it can take the indexes already available and create more optimal indexes for future use.

This relieves you of the need to recreate queries and indexes when you rearrange your data in your next release. It also prevents a hiccup in performance once you release your next build.

The Bottom Line

  • A developer can make $140,000 per year. Assume 2 weeks vacation and 5 extra days for national holidays. That’s 49 weeks. On average, a developer works around 40 hours a week, or 1,960 hours per year. That’s around $70 per hour for each developer.
  • An easy to learn training guide can save a 5 person development team 20 hours, or $1,400.
  • Our setup wizard can save a development team at least 40 hours, or, $2,800.
  • Using commodity hardware for a 7-node cluster rather than a huge server can save you $13,000.
  • The median salary for a DBA is $100k. Productivity gains net you $25,000.
  • Rapid tech support can save you thousands in not having to idle your developers or delay the release of your next build.
  • A schemaless data architecture and dynamic querying save your developers time in their next release. It also keeps performance high, especially at the point of sale. This not only saves you days of development, it increases sales right where the buying decision is solely up to the development team.

When you tally up all these savings, the total returns for using the right database on your next application can far outweigh the investment!

With your database, you shouldn’t have to pay to play. Your database should be the one paying you!

Get comfortable using NoSQL in a free, self-directed learning course provided by RavenDB. Learn to create fully-functional real-world programs on NoSQL Databases. Register today.

Topics:
database ,database scalability ,ease of use ,dynamic query

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}