Which php library to use to work with databases?

Which php library to use to work with databases?

Need the most flexible tool with stmt, what would you advise?

There are self-made, but sometimes its flexibility is not enough. For example, when you need to make a complicated comparison or to verify a regular expression, or simply to specify the limit. Initially just collected a set of functions in one class for quick work with the database for simple projects, and then went a bit challenging and need something new, preferably with a community and documentation
April 4th 20 at 13:20
4 answers
April 4th 20 at 13:22
Solution
First you need to decide what kind of tool it.
There are three kinds of tools

1. DBAL - just a class to execute queries. PDO almost 90% covers the tasks of this class.
Queries are written kinds
$user = $db->prepared_query("SELECT * FROM users WHERE id = ?", [$id])->fetch();

2. Query builder - the query Builder.
$user = $db->select('*')->from('users')->where('id', $id);

3. ORM queries are hidden inside, we only write stuff like $user = User::load($id);

Most flexible, of course, is the first.
I would second (good, because the bad are a dime a dozen), then feed the first. Without the framework. - Jaunita_Shields commented on April 4th 20 at 13:25
@Jaunita_Shields, the second good and without any framework: you can only use Doctrine DBAL from (https://www.doctrine-project.org/projects/doctrine... and juzat without any framework, as, indeed, the very Doctrine entirely, if pripret. It is not necessarily with the Symphony to use.

Minus the first and second option is that you will eventually have to write by hand Hydrator. Then there are some functions that will be the result of the query of mappit on an object (entity) methods with get/set. Of course you can just work directly with records from database as an array, but it is currently the case, because in a large project will be pandemonium, for example, when a column is removed/renamed, you will have over your climbing and change. And not the fact that somewhere you won't forget. This problem even the test coverage does not always solve, as shown.

Minus the ORM is that they are always flexible enough. I have a project where originally the Doctrine, and now I look and she's there at the end almost never used, because the queries are complex (use of a design type with out PostgreSQL, etc., which means the ORM is difficult to do), had their hands to write. - laury.Brown commented on April 4th 20 at 13:28
in a large project will be pandemonium, for example, when a column is removed/renamed, you will have over your climbing and change. And not the fact that somewhere you won't forget.

I'm willing to try :)

because the queries are complex (use of a design type with out PostgreSQL, etc., which means the ORM is difficult to do), had their hands to write.

With complex queries it is clear :)
But with a simple - tired of writing them by hand, you want sweet fluent interface.

The more that bodachs on one project is already written type-DBAL (before my time), but such a nightmare that living with him... no, not possible, but it is extremely redundant. - Jaunita_Shields commented on April 4th 20 at 13:31
@laury.Brown, doctrine allows you to use native queries.
And muppet in the manual.

I would choose the third solution.
I want to use naive, please. - Jamal_Marvin commented on April 4th 20 at 13:34
@Jamal_Marvin, so what's the point, when my micro service requests a total of 30 pieces was from the bottom only 2 or 3 were using doctrine (ORM), the rest is just native? There is no point at all in this case, the Doctrine of leave. Just for the sake of the mapper is that. - laury.Brown commented on April 4th 20 at 13:37
@laury.Brown, Well, the doctrine is not only in order to perform queries, you are well aware.

Yes, queries can be very complex.
Well, how about the fields in the database.
Migration.
But object representation that only is.

Made up a complex query, sampil manually, got the object.

There's potential... - Jamal_Marvin commented on April 4th 20 at 13:40
@Jaunita_Shields,
you want sweet fluent-interface
- I'm dbforge studio use - there in the GUI, the desired tables, fields and functions stumble, run, and once the result or an error will display and the query execution time. Quickly and easily bring the request to perfection - it's very easy to dbforge work even with complex queries. - elissa commented on April 4th 20 at 13:43
@Jamal_Marvin, migration is very often doing a third-party tool or a separate library. For example, phinx. I'm in my current project don't use Doctrine and I can say that I only hydration does not suffice. Otherwise, the queries quite clever - the Doctrine of excess (maximum kveri bilder from it something which can be adapted). And using it only for mapping the result on the object of special meaning do not see. At least at the moment. By the way, have You tried Moka doctrine for unit tests? - laury.Brown commented on April 4th 20 at 13:46
By the way, have You tried Moka doctrine for unit tests?

No, not tried.

Have a problem with that?

XS, you need to try, just brewing task.
In any case, we will test the business logic of the application, not the actual doctrine. - Jamal_Marvin commented on April 4th 20 at 13:49
@elissa, tried it, didn't come.

"Sweet fluent interface" is different. - Jaunita_Shields commented on April 4th 20 at 13:52
April 4th 20 at 13:24
Doctrine
Hydration large amount of data does not stop ? - bridie commented on April 4th 20 at 13:27
No, of course, for really large amounts gidrorem in the mountains and enjoy life - sammy.Upt commented on April 4th 20 at 13:30
April 4th 20 at 13:26
Eloquent and the query builder under it, and better together with laravel
Not better. Do not sit down the person on the needle frameworks. - Jaunita_Shields commented on April 4th 20 at 13:29
@Jaunita_Shields, the man himself asks to get him hooked. Moreover, larabel not a bad option. - broderick14 commented on April 4th 20 at 13:32
@broderick14, uh, well, the library works with databases - this is not a framework, no? - Jaunita_Shields commented on April 4th 20 at 13:35
Eloquent is one of the worst ORM from the point of view of architecture and difficulty curve, it is not necessary to use it. - sammy.Upt commented on April 4th 20 at 13:38
@sammy.Upt, and the doctrine is one of the best? - broderick14 commented on April 4th 20 at 13:41
@broderick14, right - sammy.Upt commented on April 4th 20 at 13:44
@sammy.Upt, well, they do different things a bit :)
eloquent is active record + beneath relatively normal query builder. Date mapper can be your draw when needed. And the doctrine - it is often overkill + its own sql-like language, IDE support is not very different. - broderick14 commented on April 4th 20 at 13:47
@broderick14

eloquent is active record + beneath relatively normal query builder.

nope, if we compare with AR - then at least Yii-shnaya ORM.

And the doctrine - it is often overkill

What often appears overkill?

its own sql-like language, IDE support is not very different

What, for example? - sammy.Upt commented on April 4th 20 at 13:50
April 4th 20 at 13:28
I successfully use SafeMySQL is a very fast, safe, convenient. If you need anything fanciful, it is better to add a couple of functions myself, still under all your tasks a universal library and to add a couple of SQL queries will be faster. Besides, if you do finish, you will be able to make more optimized code for your needs. For example, what about limits standard query sometimes can be very slow - more info hereand a little tweak the query, you can avoid serious delays.

Find more questions by tags PHP