Does it make sense to write your own wrapper over PDO?

Question

PHP

Actually a subject. A familiar teacher asked his students a lab - to write a wrapper class over PDO, so that, allegedly, by changing one parameter, change the type of database with which the site works. The question arose, how relevant is this task in practice and is it worth bothering with such?

Answer 1

In practice, you will still encounter specific properties of one or another database that you want / need to apply. Each database manufacturer still introduces some differences in the SQL syntax, otherwise why clone an existing project? - So, in my subjective opinion, pursuing the goal of cross-database is very utopian. It would be more reasonable to get acquainted with the specifics of a particular database and understand what it is for, and not to fence universal ruffles. The more universal the tool, the more difficult its implementation and further support.

Answer 2

In most cases, no. There is doctrine and a bunch of other ready-made libraries.

Answer 3

No, it's better to spend time studying how it is implemented by cool guys (Doctrine, Propel).

Answer 4

In some commercial CMS with which I work, a wrapper over PDO is implemented, depending on the site settings, you can work with different databases (oracle, mssql, mysql) without changing queries. So the issue seems to be relevant.

Answer 5

only if you plan to use multiple database connections or different database types

Answer 6

Out of the box, PDO is not very usable and inconvenient: it does not count time and query statistics, does not support lazy connection, connection pool, transactions, normal placeholders. because the wrapper should be written in 90% of cases.
But you won’t be able to write a wrapper that allows you to change the DBMS transparently for the code. MySQL has LIMIT, INSERT ON DUPLIATE KEY UPDATE and a bunch of stuff that other databases don't have. What will you do with them to make them work in Oracle?

Answer 7

I use a self-written query builder in my projects.
convenient for speeding up development and in case of migration to another database.
At the heart of pdo

Answer 8

It all depends on the scale of the project. With this option of switching between database types, you will have difficulty optimizing the extract / changing data.

Answer 9

Recently I watched a series of video tutorials in which such functionality was implemented as a training in the basics of OOP. Apparently, the teacher is also not averse to watching the lessons.

Answer 10

The task is not entirely clear, PDO without any wrappers out of the box is DBAL. But it’s worth learning to write wrappers, especially with iterations to increase functionality, so that entry points and extensions are thought out in advance. I have such a wrapper that is mandatory when training juniors, the profit is huge.
Regarding PDO and support for different databases, this idea does not work out of the box, because. you can write custom SQL, which may not be supported by all databases, so you need at least Query Builder.

Answer 11

at this level, this is an exclusively school task and it has no practical value - you just have to dig a little deeper than a simple select and it turns out that the engines are very different and the banal id of the last insert can cause a headache when porting.
it is necessary to abstract higher - at the level of objects and operations of working with them. the actual optimization is done already under the engine and can cause changes at the level of the order, the type of queries or individual operations. Here you can’t do without a wrapper over calls to the database.
In general, the tasks of accessing different engines are quite typical for integration (joining documents in different circulation systems, pairing VCS, tracker, test manager and business process systems), for various kinds of separation by levels ( sq-nosql, external and local, server and client )