ORM

It is necessary to ensure work with data in terms of classes, not data tables, and vice versa, to convert the terms and data of classes into data suitable for storage in a DBMS. It is also necessary to provide an interface for CRUD operations on data. In general, it is necessary to get rid of the need to write SQL code for interaction in the DBMS ^[1] .

There is a solution to the data storage problem - these are relational database management systems . Using a relational database to store object-oriented data leads to a semantic gap , forcing programmers to write software that must be able to process data in an object-oriented form and be able to save this data in a relational form. This constant need for conversion between two different forms of data not only greatly reduces performance, but also creates difficulties for programmers, since both forms of data impose restrictions on each other.

Relational databases use a set of tables representing simple data. Additional or related information is stored in other tables. Often, multiple tables are used to store a single object in a relational database; this, in turn, requires the use of the JOIN operation to obtain all the information related to the object in order to process it. For example, for storing notebook data, most likely, at least two tables will be used: people and addresses, and, possibly, even a table with phone numbers.

Since relational database management systems usually do not implement the relational representation of the physical level of relationships, the execution of several consecutive queries (related to the same “object-oriented” data structure) may be too costly. In particular, one request of the form “to find such and such a user and all his phones and all his addresses and return them in this format” will most likely be executed faster than a series of requests of the form “Find user. Find his address. Find his phones. ” This is due to the work of the optimizer and the cost of parsing the request.

Some ORM implementations automatically synchronize memory-loaded objects with the database. In order to make this possible, after creating an object-to-SQL-transforming SQL query (a class that implements communication with DB), the received data is copied to the fields of the object, as in all other ORM implementations. After that, the object must monitor the changes in these values ​​and write them to the database.

Relational database management systems show good performance on global queries that affect a large part of the database, but object-oriented access is more efficient when working with small amounts of data, as this reduces the semantic gap between the object and relational data forms.

With the simultaneous existence of these two different worlds, the complexity of the object code for working with relational databases increases, and it becomes more prone to errors. Database-based software developers were looking for an easier way to achieve the constancy of their objects.

Many packages have been developed that eliminate the need to transform objects for storage in relational databases.

Some packages solve this problem by providing class libraries that can perform such conversions automatically. Having a list of tables in the database and objects in the program, they automatically convert queries from one view to another. As a result of querying the “person” object (from the example with the address book), the necessary SQL query will be generated and executed, and the results will be “magically” converted into “phone number” objects within the program.

From the point of view of the programmer, the system should look like a permanent storage of objects. It can simply create objects and work with them as usual, and they will automatically be stored in a relational database.

In practice, everything is not so simple and obvious. All ORM systems usually manifest themselves in one form or another, reducing in some way the possibility of ignoring the database. Moreover, the transaction layer can be slow and inefficient (especially in terms of generated SQL). All this can lead to the fact that programs will run slower and use more memory than programs written "manually".

But ORM saves the programmer from writing a lot of code, often monotonous and error prone, thereby greatly increasing the speed of development. In addition, most modern ORM implementations allow the programmer, if necessary, to hardcode the SQL query code that will be used for certain actions (saving to the database, loading, searching, etc.) with a permanent object.

• Doctrine
• Tryton
• Activerecord
• Eclipselink
• Hibernate

• Noble, J., Anderson, T., Braithwaite, G., Casario, M., Tretola, R. Flex 4. Recipes for programming. - BHV-Petersburg, 2011 .-- S. 548. - 720 p.

• Scott W. Ambler: Mapping Objects to Relational Databases: O / R Mapping In Detail
• Core J2EE Design Pattern: Data Access Objects
• Citations from CiteSeer
• JPA Performance Benchmark - comparison of JPA ORM tools (Hibernate, EclipseLink, OpenJPA, DataNucleus]
• Apache Cayenne .