NoSQL Databases vs. Relational Databases

Databases are [fairly complicated] pieces of software that are designed to hold large amounts of data – text, numbers, images, even videos – and store it for retrieval and use at a later time. These days, they are often used to provide long-term data storage to computer software – everything from cellphone apps and websites, to large business systems involving many thousands of connected computers. Traditionally, everyone has used relational databases which structure information into tables and columns, and communication with these products typically requires a good knowledge of structured query language (SQL), which has a different syntax from the programming languages that applications are written in.

New types of databases, known as NoSQL databases or data stores, have become popular as a way of storing objects and information more directly – using library functions and objects from the language actually used to write the application. This is not a new concept, however, it has gained a lot of momentum with recent discussions about “big data”, and developers have begun to focus on the wider issues surrounding object-persistence rather than automatically assuming that a relational database would be used.

Traditional Databases

Relational Database Management Systems (RDBMSs) don’t offer easy integration with application code (requiring the programmer to be familiar with SQL), and they can struggle to remain effective with data that is not consistently structured. However, they are extremely strong in the areas that NoSQL databases are weaker – they excel at processing small transactions quickly and safely, especially when many processes are running at the same time. And using highly structured data can be an advantage in many cases: ensuring the integrity of information and allowing the RDBMS to make changes to one value while a completely different process is changing another value in the same record.

Commercial RDBMs can cost many thousands of dollars, but others are offered at very low price points (even free or open-source). Products like SQLite have become extremely useful for software developers, providing a server-less relational database, which removes one of the few remaining disadvantages for their use in software (particularly desktop) applications.

Key Strengths:

• Efficient at processing small changes to data that can be logged and rolled-back (undone) if required.
• Reliable and secure processing of transactions from a very large number of simultaneously connected users.
• Many operations (such as filtering and sorting data) can be handled by the database.
• Enterprise-level commercial and open-source solutions are available.
• Stable, mature technology that is widely understood and supported.

NoSQL Databases

NoSQL databases have been designed to reduce the complexity involved in working with databases from program code, and allow the software developer to store data easily in a safe and secure system.

Working with a NoSQL database can be as straightforward as calling a method from a client API or web service and passing into it the object (such as a class, or collection etc.) you want storing. You don’t need to learn any other languages, or have advanced knowledge of database architecture; everything can be done using simple calls. The database itself doesn’t place many restrictions on how the data is saved, it simply stores whatever you tell it to and the actual structure can be different for each object that is saved.

In many modern uses of databases, your application would be doing most (if not all) of the data processing (such as filtering and sorting data) and by not supporting the vast list of features of traditional solutions, NoSQL solutions can be highly-optimized for data storage and retrieval – providing excellent performance.

Key Strengths:

• Ideal for highly variable data structures, and even unstructured data.
• Accessible from the language that the software is programmed in.
• Optimized for extremely fast storage and retrieval of whole documents or objects.
• Wide variety of open-source solutions available.

However, NoSQL databases are not suitable for every application. They may not be appropriate in situations where you have thousands of users all making very small changes to data at the same time, or where the success of these “transactions” must be guaranteed. They also might be not suitable when a high level of isolation between the data storage and the running applications is desired. NoSQL databases are relatively unknown compared to other database types, and this itself can be a disadvantage when designing systems for more conservative sectors.

As NoSQL solutions grow in maturity and popularity, they provide an increasingly legitimate choice for application developers. But developers should not be too easily swayed by their programmer-friendly nature, and should ensure that the choice of database matches the needs of the application, the kind of data it will be storing, and how it will be accessed.