Имеет ли смысл писать свою обертку над PDO?

Question

[KoteSoft]

Собственно сабж. Один знакомый преподаватель задал своим студентам лабу — написать класс-обертку над PDO, чтобы, якобы, изменением одного параметра изменять тип БД, с которой работает сайт. Возник вопрос, насколько это актуальная задача на практике и стоит ли таким заморачиваться?

Answer 1

[AlexeyParhomenko]

На практике — вы все равно столкнетесь со специфичными свойствами одной или другой бд, которые вам захочется / нужно будет применить. Каждый производитель бд все равно вносит какие-то различия в SQL синтаксис, иначе зачем клон существующего проекта? — Так что преследовать цель кросс-бд по моему субъективному мнению весьма утопично. Более разумным будет ознакомится со спецификой конкретной бд и понять для чего она, а не городить универсальных рюшек. Чем более универсальный инструмент тем сложнее его реализация и дальнейшая поддержка.

Answer 2

[nick4fake]

В большинстве случаев, нет. Есть doctrine и куча других готовых библиотек.

Answer 3

[Inori]

Нет, лучше проведите время за изучением того, как это реализовано у крутых дядек (Doctrine, Propel).

Answer 4

[startsevdenis]

В некоторой коммерческой CMS с которой я работаю, реализована обертка над PDO, в зависимости от настроек сайта, можно не меняя запросов работать с различными БД (oracle, mssql, mysql). Так что видимо задача актуальна.

Comments

[Иван Климчук]

В некоторой некоммерческой CMS точно так же, там даже готовая обертка — xPDO. Речь о MODX.

Answer 5

[Алексей Фирсов]

только если планируется использовать несколько соединений с БД или разными типами БД

Answer 6

[egorinsk]

PDO из коробки малоюзабелен и неудобен: не считает время и статистику запросов, не поддерживает ленивого соедиения, пула соединений, транзакций, нормальных плейсхолдеров. потому обертку писать стоит в 90% случаев.

А вот написать обертку, позволяющую прозрачно для кода менять СУБД, у вас не получится. В MySQL есть LIMIT, INSERT ON DUPLIATE KEY UPDATE и куча вещей, которых нет в других БД. Что вы с ними делать будете, чтобы заставить работать в оракле?

Comments

[Иван Климчук]

Обертка на то и обертка, чтобы внутри себя понаписать драйверов для разных БД, а для кода это все будут одни и те же вызовы прозрачные.

Answer 7

[DrNemo]

в своих проектах использую самописный конструктор запросов.
удобно для ускорения разработки и в случае миграции на другую бд.
В основе pdo

Answer 8

[AGvin]

Все зависит от масштабов проекта. При таком варианте переключений между типами БД, у Вас будут сложности с оптимизацией вытяжки/изменении данных.

Comments

[Алексей Фирсов]

> При таком варианте переключений между типами БД, у Вас будут сложности с оптимизацией вытяжки/изменении данных.

Пояснит при каком варианте? Если обертка грамотно написана переключать БД совсем не сложно, а даже удобно.

[AGvin]

К примеру, в MySQL есть multiple INSERT, но в CouchDB, на сколько мне известно, такого функционала нету.
Да, Вы сможете проэмулировать этот функционал, но это уже не будет так эффективно.

[AGvin]

Более подробно описал AlexeyParhomenko (сейчас с пометкой «решение»)

[Алексей Фирсов]

Ну можно же использовать патерн фабрика

[AGvin]

Ну, как бы, с патерном я знаком. Но, как он тут поможет?

Answer 9

[Константин Биржаков]

Недавно смотрел серию видеоуроков, в которых такой функционал был реализован в качестве обучения основам ООП. Видимо, преподаватель тоже не прочь посмотреть уроки.

Answer 10

[Вячеслав Плиско]

Не совсем понятна задача, PDO без всяких обёрток из коробки является DBAL. А вот обёртки учиться писать стоит, особенно с итерациями по увеличению функциональности, чтобы заранее продумывали точки входа и расширения. У меня такая обёртка обязательная при обучении джуниоров, профит огромный.

По поводу PDO и поддержки разных баз данных, то эта идея из коробки не работает, т.к. можно писать кастомный SQL, который может не поддерживаться всеми БД, поэтому нужен как минимум Query Builder.

Answer 11

[Wott]

на этом уровне это исключительно школьная задача и практической ценности у нее нет — стоит только копнуть чуть глубже простого селекта и выясняется что движки сильно отличаются и банальное id последней вставки может вызвать головную боль при портировании.

абстрагироваться надо выше — на уровне обьектов и операций работы с ними. собственно оптимизация делается уже под движек и может вызвать изменения на уровне порядка, вида запросов или отдельных операций. Тут обойтись оберткой над вызовами к базе не обойтись.

А вообще задачи доступа к разным движкам достаточно характерны для интеграции ( срастить документы в разных системах оборота, сопрячь VCS, треккер, тест менеджер и системы бизнес процессов ), для разного рода разделения по уровням ( sq-nosql, внешняя и локальная, серверная и клиентская )