Editor’s Note: The following is an article written for and published in DZone’s 2021 Data Persistence Trend Report.
Conventional database systems such as MySQL or Microsoft SQL Server are based upon tables, implying rows and columns. This makes it difficult to represent relational graph objects, with records being parents and children of other records in the same table. In fact, this is one of the primary arguments for why developers are choosing NoSQL today, because it makes it so simple to represent graph objects.
In recent years, NoSQL distributed databases have become common, as they are built from the ground up to be distributed. Yet they force difficult design choices, such as choosing availability over consistency, data integrity, and ease of query, to meet their applications’ need for scale. This Refcard serves as a reference to the key characteristics of distributed SQL databases, how functionality compares across database offerings, and the criteria for designing a proof of concept.
Organizations who want to take advantage of the many benefits of NoSQL databases, often find that they have two challenges:
- How to convert their RDBMS schemas to leverage the schema-less document model.
- Learn a new API/Query to access the data.
Some also find the confusion with the NoSQL name. The abbreviation stands for 'Not only SQL', but it can also be misinterpreted it as 'No to SQL', thus accepting that in order to use NoSQL database, organizations will not only have to convert their relational data model into the document model, but also get training on whichever APIs for the NoSQL database that they will select.
