First of all, in order to provide universal and optimal access to data, there is a query language. In most cases, this is SQL (why exactly it, we will discuss further), but now I just want to draw attention to the trend. First, there was SQL for a long time – of course, there were times before it, but, nevertheless, SQL dominated for a long time. Then all sorts of Key-value-storage began to appear, which, they say, work without SQL and are much better.
Many Key-value-storage were mainly done in order to make it easier to navigate from your favorite programming language, and SQL does not fit very well with your favorite programming language. It is high-level, declarative, and we want objects, so the idea came up that SQL is not needed.
But most of these technologies now actually come up with some kind of query language. Hibernate has its own query language very well developed, some are using Lua. Even those who used Lua before make their own SQL implementations. So now the trend is this: SQL is back again, because a convenient human-readable language for working with sets is still needed.
Plus, the tabular presentation is still convenient. To one degree or another, many databases still have tables, and this is far from coincidental – this makes it easier to optimize queries. All optimization mathematics is tied around relational algebra, and when you have SQL and tables, it’s much easier to work.
In the storage layer there is such a thing as serialization. When there is parallelism and concurrent access, we need to ensure that it arrives on the processor, on the disk in a more or less predictable order. This requires serialization algorithms that are implemented in the storage layer.
