Php обёртка базы данной для возможности смены движка db

Подскажите паттерн, которым обернуть все вызовы db, чтоб можно было потом добавить в код возможность работы с другим движком. Например, сейчас mongodb, а потом дописать, чтоб то же самое работало для mysql.

Вообще PDO, но nosql оно не поддерживает.

А как поступить, если я сам буду писать реализации под конкретные базы, включая простейший вариант в текстовом файле.
Например есть абстрактный класс, в котором обьявдены все нужные методы работы с абстрактной БД. Как реализовать смену реализации этого абсмтрактного класса, налету, в зависимости от настроек скрипта? Самый тупой спобоб, который приходит в голову, это смана файла инклуда с реализацией. Но это не совсем уже ООП! Ибо таким макром можно и процедуры обёртки инклудить с разной реализацией, раскидав их по разным файлам!

ОРМ для реляционных БД реализована
скорее всего свой велосипед писать
ибо принципиально разные подходы к хранению данных

Цитата:

Как реализовать смену реализации этого абсмтрактного класса, налету, в зависимости от настроек скрипта?

интерфейсом например

Sterx писал:

интерфейсом например

Можешь схематически показать или дать линк на что-то похожее?

Код: [развернуть]

<?php interface DataBaseMapper {     public function selectItem($id);     public function selectItems($ids); } class MysqlMapper implements DataBaseMapper {     public function selectItem($id)     {         return .....;     }         public function selectItems($ids)     {         return .....;     } } class MongoDBMapper implements DataBaseMapper {     public function selectItem($id)     {         return .....;     }         public function selectItems($ids)     {         return .....;     } }

таким образом в абстракции имеем набор методов одинаковых для каждого нового интерфейса, каждый из методов имеет свою реализацию для конкретной БД

Sterx: А как это будет выглядеть в коде, где надо использовать конкретно базу в зависимости от какого-то условия? Предположим, для простоты в конфиге есть настройка $dbEngine = 'Mysql'; //или 'MongoDB'; (Или статический класс с тем же примерно полем по смыслу..) Как эта нвстройка должна влиять на код?

И как в самом файле, где нужно обращаться к базе использовать эту абстракцию? (Т.е. элементарно вызвать selectItems..)

Код: [развернуть]

<?php     $dbEngine = 'MysqlMapper';     $db = new $dbEngine();     print_r($db->selectItem(123));

Почему ты тогда не посмотреть в сторону doctrine, propel. Потратить время на обучение, но потом сильно сэкономить на изготовлении своего велосипеда.

Тем более имхо переход mongodb -> mysql весьма специфичный, что бы все предусмотреть заранее. А в orm уже более менее решено.

в doctrine и nosql и sql дружат?

Да, так как ты работаешь с объектами записей. А хранение, выборка и прочее уже за тебя решает сам ORM. Конечно же такое будет не бесплатно, а стоить дополнительных серверных ресурсов.
Тот же symfony вроде как раз doctrine использует в качестве прослойки работы с базой данных.

Имхо такие переходники писать разово нужно. Не каждый день бд меняешь.
Поэтому смысла с такими заморочками абсолютно не вижу. К тому же с такими велосипедами потеряешь в производительности.
Касаемо паттернов. Основных пара это Active Record и Data Mapper.

Stek писал:

Почему ты тогда не посмотреть в сторону doctrine, propel. Потратить время на обучение, но потом сильно сэкономить на изготовлении своего велосипеда.

Потом чтобы в готовом проекте колонку в таблице добавить столько гемору словить..

использовать ORM - но лучше написать свой слой для бизнес логики (набор функций на уровне бизнес логики а не абстракции на уровне драйвера).

т.к. при использованиие orm боремся с инструментом вместо реализации приложения

gcc писал:

Потом чтобы в готовом проекте колонку в таблице добавить столько гемору словить..

А при чем тут добавление колонки, если изначально разговор шел о обертке над базой, что бы можно было с mongo на mysql съехать.

S_Flash писал:

Самый тупой спобоб, который приходит в голову, это смана файла инклуда с реализацией. Но это не совсем уже ООП! Ибо таким макром можно и процедуры обёртки инклудить с разной реализацией, раскидав их по разным файлам!

ну и что?
вполне нормальный способ чем городить какие то классы с интерфейсами.

require "dblayer/mysql.php";
//require dblayer/mongodb.php;

в файле реализуем несколько функции

entitySelect($table, $filter) - выборка списка элементов

entityGet($table, $key) - возвратить по ключу

entitySet($table, $key, $data) - сохранить по ключу

entityDelete($table, $key)

этих функций в принципе достаточно

вопрос личностной дрочки - у кого то стоит на ООП стайл, у кого то на функции

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