In addition to the practical problems mentioned above, the use of RDBs has recently seen other important trends.

Because of the excessive "rigidity" of the relational model, its major practical (not theoretical) drawback is the complexity of data manipulation. The first option is to use the pipeline of operations on sets - join, intersection, filtering, etc. in practice, it is almost never used, since it is associated with the expenditure of colossal resources and is justified only with "batch" processing of sets of requests of the same type. The second option - the SQL interpreter requires high professionalism, good knowledge of set theory, database theory, and considerable practical experience.

Object-Oriented Programming (OOP) in languages ​​has become the standard, but SQL is a declarative language and is not good friends with OOP. As a result, the solution to the problem of matching application program code with SQL queries based on a class library called ORM (Object-Relational Mapping (Transformation) [9]) has gained popularity.

Using ORM classes allows the programmer to do without SQL when using RDBs. ORM automatically generates SQL queries to the RDBs to create tables and manipulate data. Most ORMs have interfaces with various popular DBMSs - SQLite, MySQL, PostgreSQL and others, which gives a choice without modifying the program code.

There are many ORM implementations, even several for each programming language. All of them are similar, so for definiteness in the future, by ORM we mean the corresponding library (package) of models of the Model class of the Django framework [10] in the Python language [11].

ORM is very “convenient” and numerous programmers don’t really think that using this API they get not only the advantages of the relational model, but all its disadvantages. For example, in the code itself, you cannot override table models — add or remove a column, add a new table, etc. To make the database migration, you must first rewrite the code, then "rise one floor higher", and then restart the program. As a result, it is impossible to create an application that provides for even the simplest changes to the data scheme during the operation of the program without changing the program itself.

Data search in ORM is implemented using chains of methods, for example, “objects.all ()”, “objects.get (...)”, “objects.filter (...)” in Django. Simple, beautiful and convenient, but what algorithmic complexity of executing SQL-queries generated by ORM, this will lead to, is not visible to the naked eye.

When a person writes an SQL query, it is assumed that he thinks and understands the cost of computing resources. ORM veils this task. Therefore, in serious projects, ORM is practically not used due to the inefficiency of the generated SQL queries for structurally complex and large databases.