PDO or ORM in PHP?

Question

PHP

I used to develop all projects based on PDO DB. Now, having read many books and articles, I began to wonder if I am using the right approach? Everywhere there are tips on using Doctrine or Propel as a more convenient tool. Yes, I liked the format of the work on the given examples. But will these libraries be able to create complex queries with several JOINs, for example, and in general, how will the use of these libraries affect performance?
Therefore, the question to the public: "What do you use to access the database, and why did you choose this particular method?".

Answer 1

Simple queries (80 percent of them) simplify the form of course, but if you need a non-standard, then it's easier to do native sql. IMHO of course.

Answer 2

Also asked a similar question. I tried the doctrine and sang, but threw them away because of the great gluttony and crutches for complex requests. Also annoying was the huge number of auxiliary files (base classes, mappers, etc.) for each model generated by these libraries. As a result, I made my own ORM based on Zend_Db_Table, Zend_Select (this is especially beneficial when the project itself is built on ZF).
For simple cases it is convenient to use Active Record. I consider AR in the Yii framework to be the most successful example of implementation.

Answer 3

I like the approach used in the Yii framework - simple queries can be implemented using an ORM, while for complex queries there is a lower level of abstraction based on PDO. Thus, both approaches can be combined depending on the complexity of one or another element of the project.

Answer 4

There is such a thing as a php forum: www.phpclub.ru/
Where there is a search, and there are many more experienced people (and not (more) beginners like on Habré).
Although I sincerely hope that they will be able to suggest here ...

Answer 5

I used the doctrine (in the symphony) - it's convenient, you can do joins. Everything is clear and beautiful, there is documentation.
Of the minuses - it consumes a lot of memory.

Answer 6

Error in understanding the difference between PDO and ORM, the question sounds like "spoon or plate at dinner"
PDO is DBAL - a simple interface for working with a database that provides the same methods for working with different databases, so you don't have to think about which one DB we are working at the moment.
ORM - Wikipedia - is a programming technique for converting data between incompatible type systems in object-oriented programming languages. Those. a technique for converting ordinary tables, as in relational databases, into objects. This is obvious, it is difficult to work with ordinary arrays, and FETCH_OBJECT is still not an OO approach.
One technology complements another.
Now about propel and doctrine.
I didn't like Doctrine 1 because they added a bunch of incomprehensible features to it, and as a result, a mess came out that was difficult to learn (for example, three ways to extract data from an entity, an incomprehensible 'Table' abstraction).
Propel. rather dead than alive. It was raised and supported now by only one person. I didn’t like the fact that 6 incomprehensible classes are generated for one entity, and the generation process itself bothers
Doctrine 2, it’s practically hibernate for php %) compared to the first version, it was cleared of garbage, made it a data mapper. What I like is a clear interface, pure domain objects (entities) - the entire config can be placed in the annotation / xml / yaml. As a result, all models look as simple as class news {private $title; private $text; }. Stopped on it.

Answer 7

At one time we thought about how to switch to ORM, considered Propel, but then we implemented Yii and began to use its built-in ActiveRecord. For most tasks, it does an excellent job.
Well, for complex, and especially large selections (more than a thousand records), the use of ORM is highly discouraged.

Answer 8

ORM is good when there are a lot of simple queries and domain entities fit well into the database structure - it speeds up the creation of model classes. Complex queries using the methods provided by the ORM are usually written for a long time and most likely not very clear and beautiful code will come out. Here IMHO native SQL is better.

Answer 9

There are times when the ORM can't handle a request. Just nothing.
And there are requests when native SQL input also cannot cope with the request.
Problems can be both technical and architectural or high-speed.
But in any case, the more cunning and original the binding over the final database is, the better.
Starting from working with a database in several connections, ending with working with several databases, or tables partitioned on several servers. Or even a direct mapping to the sphinx.
So draw what you need now, draw as much there from your head, from what theoretically you may suddenly need later.
Assemble into a single system.
And under this system, look for a tool.
But never use pure SQL - at least queries through your wrapper. At least vozmozhnost as either easy to change (or find in the query) table names.

Answer 10

In my experience, when fine-tuning libraries that implement ORM (first of all, setting up lazy load for almost every request), the overhead when executing from them is small (compared to the actual execution of the request) and is fully compensated by simplifying development and support, if you do not need to use "exotic" type of stored procedures or triggers.

Answer 11

I will tell you where it is not necessary to use Doctrine 1.2 or Propel - in long-running scripts.
The doctrine eats memory out of the blue and you can’t cope with it in any way, sooner or later you will reach the memory limit.
In other cases, the choice of ORM is justified.

Answer 12

Once upon a time, I didn’t understand why these ORMs were needed - after all, you can write a miniature shell over mysqli / PDO and use it (which I did in home projects, but at work at that time I worked with Yii2 and Active Record, respectively, which is completely I liked it), until... on my self-written bicycle I faced the task:
1. Take all the fields from a table with 70+ columns
2. Make a form, with editing each field
3. Save updated data
What is on the ORM done in a few lines - I, in my small wrapper, had to do the whole evening - prescribe all the fields, prescribe each input, etc. In general, that evening I understood why ORM is needed :)
Although, in terms of performance - the thinner the layer between the project and the base - the better.

Answer 13

ORM and native SQL are completely different approaches and everyone decides for himself and for each specific project what to use.
If you understand ORM in addition to SQL, you will only gain experience. But the advice to use the doctrine is far from being everywhere.

Answer 14

In addition to the ORM itself (that is, the ability to work with records from a table as instances of a class), the query builder is also very useful, although it seems foreign and inconvenient at first glance.
For example, the use of Propel Criteria greatly simplifies the process of assembling complex queries and improves the readability of the code (goodbye to endless sprintf and other operations with strings), there are enough opportunities in 99% of cases.
If hydration (the process of generating objects from the result of a query) turns out to be a bottle neck, for example, when displaying a larger list with joins in a bunch of tables, you can refuse it in the prop and use pdo::fetch, while using the criterion.
I believe that doctrine has a similar functionality.

Answer 15

ORM is very handy. Many implementations allow you to perform not only simple queries, but also all sorts of joins, unions, subqueries, etc. I used raw queries several times in cakephp as part of the project to implement more sophisticated logic. However, after a closer reading of the documentation, it turned out that all this was easier to do within the framework of the ORM functionality.
In any case, any ORM allows you to perform "raw" queries, so there should be no problems.

Answer 16

Depends on the task, if this is a simple site with an admin panel based on the CRUD principle, then ORM greatly simplifies and speeds up development.
If this is a highly loaded project, then ORM can give an excessive overhead and fail on complex queries.
But, nothing prevents you from combining both approaches, for example, ORM for the admin panel and DAO for the frontend.
I advise you to look at the implementation of ORM and DAO in Yii. Read the section about the database in the guide , evaluate the possibilities of both approaches.

Answer 17

I use Doctrine + own extensions of this wonderful ORM. Regarding memory gluttony, there is an excellent query cacher that caches the operation of parsing a DQL query into SQL. Other brakes may be due to:
1. A healthy query with a bunch of JOINs. But here, as it were, there are no questions for Doctrine.
2. Large sample size. Actually it is necessary to limit and everything will be ok. Or, again, cache.
The biggest plus of Doctrine, it seems to me, is the ability to tweak what you need and where you need it, which I regularly use, supporting my extension library (without touching the distribution itself). Those. you can quite easily write both high-level queries a la DSL and low-level queries using NativeSQL.
There is already a solution for a bunch of files, php5-fpm + apc cacher. It is loaded once and remains to hang in memory.
Yes, the second one is even better. I plan to switch to it as soon as it is released :-)