Классы абстрактного доступа к БД vs SQL диалекты

[BeGe]

Классы абстрактного доступа к БД vs SQL диалекты

Сейчас есть.
Класс ADODB
PearDB
появилось пару новых.
Объект PDO
расширение mysqli

С другой стороны функции которые есть в самих базах и которые не является стандартом ANSI SQL.

Смысл тогда писать приложения c использованием абстрактного доступа, когда мы используем на 100% функциональность базы данных, процедуры в MSSQL и PostgreSQL, и используем кучу функций для работы с данными в MySQL (предварительная обработка данных)

Используя ANSI SQL мы переносим часть вычеслений на строну php хотя могли и обработать эти данные и в базе данных теряем производительность, и ещё загружаем класс надстройки.. что не даёт прирост в производительноси.

Знаю что найдутся и те которые скажут что класс для работы с базой данных, будет мизером относительно других, но всё же это мизер. Надеюсь что вы помните старый анекдот о нехватки одного байта ?

Так какая же золотая середина для доступа к базам данных, что бы использовать функционал базы данных на полную и получить достаточно лёгкую перносимость между базами данных ?

Есть решение создавать отдельный класс для пректа - класс доступа к данным - и перписывать этот класс под каждую базу данных отдельно, но тогда есть вопрос.

Есть класс dbtree для работы с деревом, вот сейчас хочу переписать его под PDO и синтаксис php5, задача по сути тривиальная, но! Скорее всего будет два класса, один общий и второй заточеный под mysql.

Вот такие вот мысли не радостные. Может кто что скажет по этому поводу, расскажет что-то новое.

 

[kvf77]

BeGe

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

Не знаю о каком классе ты говоришь, может и о моем (dbtree), но можешь глянуть в новой версии своей библиотеки (которая изначально была заточена под ADODB) я предложил аналог - драйвер для прямой работы с базами - в частности, я написал драйвер низкоуровневого, так скажем, доступа к Mysql. если интересно - глянь, может у тебя и появятся идеи своего драйвера. Драйвер-пример занимает всего 6 кб., конечно тягаться с ADODB он не может, однако почти полностью эмулирует ее функционал в рамках потребностей моего класса:

http://php.russofile.ru/ru/authors/sql/nestedsets01/

 

[BeGe]

kvf77 твой класс.
Свой драйвер писать не буду - ума хватает чужие использовать.
Посмотрим что покажут тесты через пару дней. Работа с разными драйверами при больших деревьях.

 

[kvf77]

BeGe
Ну пока я ADODB доволен и не испытываю потребности менять ее.

правда в ближайшее время буду тоже юзать PDO (после релиза 5.1) и PHP5 становится насущной необходимостью - так что и под нее скоро либа будет переписана, но сроки не говорю, потому как на данный момент есть вещи важнее, тем более что либа прекрасно работает на PHP5 в том виде как есть

 

[ForJest]

http://thatlinks.com/php/db-layers.gif
Вот небольшая принципиальная схема архитектуры приложения (изложено в докладе прошлой конференции - читайте php_inside).
В целом - все операции по работе с СУБД выгодно рассматривать как Stored Procedures. Если их нет - мы эмулируем их на PHP.
Что это даёт. Это даёт дублирование кода для всех СУБД - никому не придёт в голову что MySQL и PostgreSQL могут пользоваться ОДНОЙ и той же встроенной процедурой.
MySQL не может использовать встроенные процедуры pg. И не MSSQL не может.
При подобном рассмотрении мы получаем - каждая СУБД имеет свой собсвенный код для обработки ВСЕХ операций. Даже если он дублированный - строчка в строчку. Просто представляем некоторый слой написанный на PHP как эмуляцию SP для тех СУБД, которые не имеют данной возможности.
Итого
1. Не нужны построители запросов - все операции выполняются в SP
2. Не нужно заботится о совместимости синтаксиа - все операции выполняются в SP
3. Не нужны библиотеки абстрактного доступа - все классы-клиенты работают с "драйвером" СУБД через интерфейс, который мы написали мы. Свои параметры, свои протоколы.
4. Абстрактный доступ, построители запросов можно использовать для эмуляции SP - чтобы сократить количество кода. Но использование его должно быть подчиненно общей концепции разделения приложения на различные уровни доступа к СУБД.

 

[crocodile2u]

ForJest
Имхо, одна из наиболее выгодных схем. В последнее время активно использую, и нарадоваться не могу.

 

[kvf77]

crocodile2u

везет вам, меня вот пересадили на муську - так никаких вам прелестей хранимых процедур :-(

 

[crocodile2u]

Ну. я сейчас использую MySQL и Postgres. Пишу приложение, кот. должно работать и там и там, в зависимости от выбора юзера. Естественно, хочется оставить для лазейку для расширяемости - кто ж его знает, а может, и еще какую БД добавим? В этой связи действую прямо по диаграмме, кот. привел ForJest

 

[BeGe]

С подходом ForJest знаком, был на конфе, но тогда прийдётся написать класс DBTree под каждую базу.

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

 

[ForJest]

BeGe
Ты хочешь чего? Иметь DBTree под нужные базы? Или не иметь "лишнего дублирования"?

 

[crocodile2u]

Кроме того, я использую построение запросов при помощи специального враппера. Запрос строится на основании шаблона запроса (в шаблоне, в placeholders, описывается типы данных+еще кой-какая инфа) и собственно данных, которыми этот шаблон нужно заполнить. Естественно, для каждой БД свой враппер (наследует от базового). Это позволяет в 90% случаев простые запросы не дублировать в драйвере, скажем дерева, который заточен под конкретную БД, а использовать опять-таки унаследованные базовые методы. Враппер заквотирует все, что нужно и так, как нужно (идентификаторы - так, строки - так, числа - никак), приведет к нужному типу и т. д.

 

[kvf77]

BeGe

я вот одного не пойму - мой класс содержит достаточно оптимальные готовые SQL запросы - че ты там под базы собрался оптимизировать объясни мне? там просто запрос который надо выполнить и НИЧЕГО большего - что оптимизировать собрался расскажи? может я и сам прозрею и соптимизирую

 

[Gorath]

crocodile2u
не выложишь код куда-нть?
очень интересно разобраться..

 

[crocodile2u]

Gorath
Пиши в личку. Я пока не готов выкладывать на всеобщее обозрение.