Прозрачная работа с несколькими базами данных на PHP

[PeaceCoder]

Тема следующая. Приходилось ли работать с несколькими базами данных на одном сервере ? Если кому и приходилось расскажите какие были проблемы ?
Зачем: Надоели стандартные методы работы с базой. Думаю создать модуль, который будет прозрачен для разработчика, за счет которого можно работать с любой базой данных любого типа в любой момент, указав всего лишь тип (mysql,mssql и т.п.) и название базы данных (его указываешь в настройках баз), а на выходе получить обьект с (договоренными/обще принятыми) методами типа ->query, ->next и т.п. Вся инфа по тому как сделать запрос, генерация ошибок, колво строк и т.п. выполняет сам полученный обьект...

[Kolyaj]

http://ru.wikipedia.org/wiki/PHP_Data_Objects
http://ru.wikipedia.org/wiki/ORM

[Tim]

http://framework.zend.com/manual/ru/zend.db.html
Советую почитать перед началом - можно подчерпнуть много полезных идей. Сам ни чего такого ещё не делал, но планирую. Вообще идея хорошая ибо для добавления поддержки очередного СУБД нужно править только один класс, да и объекты как-то симпатичнее кучи переменных в глобальном пространстве.

[PeaceCoder]

СУБД нужно править только один класс

в моем случае ничего даже править не надо. в setup файле надо будет указать тип базы необходимые интсал запросы и идентификатор в модуле.
А в самом модуле будет так:

$db = F_SQL::dbo('Название модуля','идентификатор базы')
$db->q("SELECT * FROM {$db->__}название таблицы");
echo $db->count; //количество полученных строк запроса
while ($r = $db->next()){
  ...
  }

...

где $db->__ - префикс для работы с таблицами модуля.
тем самым модуль прозрачен к сайту полность. все настраивается админом, какой главнй префикс. к какой базе привязан модуль и т.п.

[e1f]

$db->q("SELECT * FROM {$db->__}название таблицы");

Вот и первый плохой подход.
При подобном проектировании, конечная цель -- вообще избавиться от sql везде, кроме как непосредственно в классах, реализующих каждый database engine. Правильно как-то так:

$db->get_object_list($type, $tbl_name, $fields, $filter, $offset, $count);

[PeaceCoder]

Правильно как-то так:

и как этим методом ты предлагаешь гибкость выборки ? Твой метод как раз плох. Ты пытаешься исключить вообще запросы, прибегая к жесточайшим методам. Это не то, на что я нацелен.
В моем случае не играет роли на каком языке написан запрос. При создании обьекта $db в нем уже будут готовые функции для работы с тем или инным типом базы данных. В твоем же случае я не представляю как это сделать. Ведь синтаксис разных баз разный... и преобразовывать один в другой просто как минимум лишняя трата времени, а во вторых не файл что преобразование будет правильным.

[e1f]

В моем случае не играет роли на каком языке написан запрос.

Мда? То есть в коде проекта будет sql-строка. А если некоторый формат базы не поддерживает синтаксис, используемый в ней? А если мы решили вообще отказаться от sql? Если делать грамотный Storage-wrapper, то от запросов везде, кроме как в классах, реализующих функционал для каждого типа БД, надо бежать как от огня.
В этом случае да, мы просто в конфиге меняем класс, который будет использоватся, и кушам печенье. Иначе мы бегаем, высунув язык, по коду, и меняем ручками запросы, которые ВНЕЗАПНО перестали работать на другой БД.

[Tim]

e1f,


PeaceCoder,
Zend и ещё раз Zend. Семое главное это архитектура (идея как всё должно работать). Реализовать сможет любой, у кого есть более или менее прямые руки. Если сейчас архитектуру не додумать то потом уже не исправить, только переделывать.

[sergdev]

Сдается мне что уже есть такое - тот же самый PEAR DB packages (с Zendом не работал).
Или не прав ?

[Tim]

sergdev,
всё верно, такого много, но это всё ЧУЖОЙ КОД.