Новая тема   Ответить

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

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

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

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

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

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

 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 .....;
    }
}

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

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

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

 Sterx

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

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

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

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

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

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

 IgorZ
Stek писал:

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

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

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

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

 rickdeckard
S_Flash писал:

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

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

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

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

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

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

entityDelete($table, $key)

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

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

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