What is an ORM for?

Question

Doctrine ORM

No, I don't understand why replace the SQL language with your own?
Why do you need to make a class whose methods take the name of the table, accept the condition for the phrases WHERE, GROUP BY, HAVING.

In fact, the SQL language has been replaced by its own language. And besides, this language is limited to the methods that the ORM provides.
Neither you hierarchical requests to pee, nor you to make an internal select.

So what's the benefit?

Answer 1

Are you confusing ORM with DBAL? ORM is not a replacement technology SELECT * FROM goods WHERE cost < 100.00for $db->select()->from('goods')->where('cost < 100.00'). ORM is a way to define the relationship between objects and RDBMS. In fact, it allows you to abstract from the way objects are stored in general, easily moving from SQL to NoSQL, memcache, files or REST / RPC API on a remote server, operating at the model level (if we talk about MVC, etc.) with simple plain old objects, and give their persistence to the controller. Not $db->select()->from('goods'),, not mysql_query('SELECT * FROM goods'), but $goodsRepository->findAll(), and the repository will form an SQL query, read files or memory, or it can knock on Google and parse its output - it, the repository, a private matter (as well as the developer(s) responsible for the storage subsystem).
In addition, ORM, as a rule, does not exclude accessing the database at the level of arbitrary SQL queries, it only converts the results of these queries into domain model objects (and vice versa), which know nothing (ideally) about tables, WHERE, HAVING, etc. P.
ORM is not only a tool for the architectural separation of areas of responsibility of objects and application classes, but also a tool for facilitating the division of labor for developers: those who are good at SQL in general and the features of a particular engine in particular work on the “other side” of ORM, optimize it as they want, and can normalize and denormalize, for example; who is well versed in debits and credits - works with plain old objects in terms of the subject area and may not know anything about SQL at all, he just needs to know that he can always get an object or a collection of them by referring to methods like findById() or findAll( ) and save the result of the work using the save() or flush() method.

Answer 2

By itself, ORM, just like maaping, is needed very much in large projects. I will describe my experience here. If someone likes it, maybe an article later.
So.
Imagine - I have a very large system, and there is an orders table in it, let's say, 50 columns in it (in fact, we have 150, but oh well. Normalizers, be silent! I also know about normal forms). And now you need to choose one order and show it on the screen. Let's say you write a select, it doesn't matter. What to do next, in the intermediate layer? You're not calling a stored procedure (query) directly from, say, a JSP page (hopefully), you still need to get the data and pass it in somehow.
So, pass them as an array, ArrayList-a, associative array column name/value? Well, so wildly cumbersome, inconvenient, and very easy to make a mistake. And if you need several orders, then what, create nested collections to convert the results? It's inconvenient.
Therefore, obviously, we need an Order object that has all the necessary properties, and we need code that can convert the results of a query into these objects (or a collection of these objects).
Further, it is obvious that writing _all_ queries by hand is difficult and tedious, it is easy to make a mistake, because in Java, they will be represented in the code as strings (which means no static typing and compile-time checks, etc., etc.), and they must be kept either in Java code (if they are small), or, if larger, put into separate XML files.
In general, ORM in large projects is needed to simplify the routine part. Without him - nowhere :)
Of course, ORM ONLY will not work. We have a lot of places where complex logic is written in stored procedures of 500-1000 lines in PL / SQL, written through ORM / Java, it would take 10 times more and work 2 times slower (at the same time, it would also less understandable, because there is such logic that is described much easier in terms of relational algebra than in terms of OOP :), therefore it falls on ORM with a creak). How much complex queries with subqueries, unions, tricky joins are also cumbersome to write through pure ORM. It is also extremely difficult to optimize queries that work in tables with at least several hundred million records without access to SQL optimizer plans and statistics / DBMS-level monitoring tools. So without SQL, too - nowhere :)

Answer 3

> So what's the benefit?
Have you tried maintaining a project that supports 5-6 RDBMS?

Answer 4

In my humble opinion, ORM was invented by people who find it difficult to think in set theory, which is necessary for understanding and correctly using SQL.
The practical use of ORM in serious projects is slightly less than from some, God forgive me, scrum.
In small ones, the only real benefit is that someone will consider himself a cool OOP programmer.
As always, I recommend the article:
citforum.ru/database/articles/vietnam/

Answer 5

some interface for working with data, which does not matter in what form and where it is located ... in the code it is very convenient to work with an object that represents a certain set of data ...

Answer 6

To write queries in your own programming language, and not integrate another language into the source code.

Answer 7

I have many similar modules in my project that represent objects. You can select one object from the database, you can select many objects. All this for any field or set of fields. And here earlier it was necessary to write a bunch of the same type of requests for each such module for all these actions. After implementing an ORM, all you have to do is add a few lines of customization to the module and all these methods are immediately available. That is, development becomes faster due to the elimination of routine. We write quite complex queries, of course, in pure SQL, but simple ORM performs with a bang.

Answer 8

We use C#, DataObjects.Net
ORM with CodeFirst methodology greatly simplifies database maintenance.
Examples:
1. Removed a field from the table - we need to check in some tricky way all queries that can use this field. In the case of working through the ORM, we will not be able to write the wrong request already at the compilation stage.
2. Renaming the field - with ORM we can use all the features of such things as Resharper, and automatically rename where necessary.
3. Not the highest optimality of requests through ORM is partially compensated by the possibility of caching on appserv, as well as the ability to execute some requests on appserv (taking into account the easy scalability of the latter)
4. As an add. bonus, although not particularly used by us - we get portability to other databases

Answer 9

For simple queries, this is more convenient. You just build the query as a constructor, INSERT and UPDATE are also incredibly handy. Just pass an associative array as an argument. At least that's how it is in Zend_DB.
And complex and nested queries all exactly have to be written with pens.

Answer 10

What does it mean - why? To represent query results as language objects. How else do you propose to work with query results?
Let's talk about the subject. Show the code that makes the request and shows the results to the user. And let's see if this code can be made better with an ORM.
PS I'm working with Entity Framework 4.0 and it's great.

Answer 11

wrote an article here - habrahabr.ru/blogs/programming/123293/