Application Data Access – closing the circle

Applications and data access development have come a long way and curiously now is the circle closes.
In the early years an application’s code was merely a reflection of the data it was meant to store and retrieve. For instance, a COBOL commarea from a program meant to access data on IBM IMS database had the structure that mapped to the data, on it’s various possibilities. Alongside with the CRUD methods implementation.

If you wanted to search through the data, you had to develop the code for it. That was achievable to the developers but consequently no Ad-hoc queries were possible for the end-users. Business intelligence was nothing but some pen and pencil with big paper stacks.
Then came relational databases. The Relational model, first proposed in 1970 by Edgar F. Codd, departed from this tradition by insisting that applications should search for data by content, rather than by following links. This was considered necessary to allow the content of the database to evolve without constant rewriting of applications.

Relational systems placed heavy demands on processing resources, and it was not until the mid 1980s that computing hardware became powerful enough to allow them to be widely deployed. By the early 1990s, however, relational systems were dominant for all large-scale data processing applications, and they remain dominant today.
The dominant database language is the standard SQL for the Relational model, which has influenced database languages also for other data models.
Finally to make my point about what this post is about, comes the trend of handling large data stores with NoSQL. It does not use SQL as its query language. NoSQL database systems rose alongside major Internet companies, such as Google, Amazon, and Facebook, which had significantly different challenges in dealing with huge quantities of data that the traditional RDBMS solutions could not cope with.

NoSQL database systems are developed to manage large volumes of data that do not necessarily follow a fixed schema. Data is partitioned among different machines (for performance reasons and size limitations) so JOIN operations are not usable and it differs from the early days IMS hierarchical database because ACID guarantees are not given.
Nevertheless, we’ve gone back to key/object systems with little flexibility, highly optimized for retrieve and append operations and often offer little functionality beyond record storage.
I state again that data development has gone full circle.