The Dawn of the Relational DatabaseBefore 1970, databases tended to be hierarchical. They were built along the structure of a branching diagram, with entities firmly under each category. For example, spoons were categorized under silverware, which was also categorized under kitchen utensils. This kind of approach to information sometimes tended to be too rigid to capture subtle concepts like the spork or kitchen scissors. Then E.F. Codd and his colleagues at IBM introduced a new kind of database in a paper called “A Relational Model of Data for Large Shared Data Banks.” It certainly wasn’t a bestseller, but this discussion opened up an entirely new way of working with information for IT professionals. The idea behind the relational model is that the database’s schema, which is the logical organization of the information, is disconnected from physical information stored in the database. Categories can change and combine in original ways based on the search functions. In this kind of information structure, scissors can be related to kitchen utensils but also to craft supplies. Answers depend on the questions the database administrator asks. For the last forty years or so, this has been the new standard organizational model for all large scale data management tasks. By the 1980s, the new standard way to pull information from these growing databases, which commonly resided on mainframes, was using a system of Structured Query Language (SQL). Components such as IF THEN statements, JOINS and variables made it easy to put up extremely detailed data on command, and databases expanded in size exponentially. That’s when relational databases began to be referred to as SQL databases.
Introducing the NoSQL DatabaseNon-relational, or NoSQL, databases never went away really, but they found new life after the turn of the millennium. The complex relationships and vast amounts of data required by search engine algorithms to find individual websites stretched the limits of queries. There have been many different approaches to cataloging data in new ways. Some of the most common types of NoSQL databases include:
Key-value storesThese are the simplest kind of NoSQL database, where each item has a key and a value. They are most often used today for managing session information for web applications. Ex: Facebook
Graph storesThese contain and manage information about networks of data, like highly complex socialconnections. Ex: Amazon’s Web Services
Wide-column stores or distributed storageThese manage structured data that can scale to very large sizes rapidly, such as petabytes of data across thousands of servers. Ex: Google
Which Is Better?As you probably guessed already, the answer is, “It depends.” If you want to work on advanced data stack for handling big data, real-time analysis and vast supply chains, NoSQL is the only way to go. Queries take too long and use up too many system resources. When you need to use a massively distributed computing resource, you want to consider some NoSQL options. Conversely, if you are working with customer relationship management (CRM), internal document version control or content marketing, a relational database is fast and easy. SQL queries can be saved and modified simply, even without a lot of IT experience. Of course, you always have the option to leave it up to the guys in development to decide which kind of database structure you need. They will certainly have their own preferences and experience with each.
For more information on relational vs NoSQL databases, please visit our website and contact our team today.