Создание специального класса, инкапсулирующего SQL запрос

pachanga

Новичок
Создание специального класса, инкапсулирующего SQL запрос

Вопрос к разработчикам: никому не приходилось разрабатывать класс, который бы полностью инкапсулировал SQL запрос и на выходе выдавал бы строку SQL.

Т.е конструрирование запроса полностью происходит с помощью объекта этого класса.
Таких классов скорее несколько SelectSQL, InsertSQL и UpdateSQL, хотя может это и некий комбайн.

Быть может, кто подскажет полезные линки, не хочется еще раз придумывать колесо.
 

AlexVN

Новичок
Мне приходилось. Я сделал так:
Сама таблица:
users
login PK varchar(15)
pwd varchar(15)

$table =& $db->getTable('users');
$table->insert(array('login' => 'pacha', 'pwd' => 'oop'));
$table->update(array('pwd' => 'oop'), 'pacha');
$table->delete('pacha');


При этом методы-построители сами узнают о PK поле и проверяют данные на валидность в соответствии с информацией о таблице и с дополнительными проверками из вспомогательного описания данных.
 

pachanga

Новичок
Автор оригинала: AlexVN
Мне приходилось. Я сделал так:
Сама таблица:
users
login PK varchar(15)
pwd varchar(15)

$table =& $db->getTable('users');
$table->insert(array('login' => 'pacha', 'pwd' => 'oop'));
$table->update(array('pwd' => 'oop'), 'pacha');
$table->delete('pacha');


При этом методы-построители сами узнают о PK поле и проверяют данные на валидность в соответствии с информацией о таблице и с дополнительными проверками из вспомогательного описания данных.
Как у тебя реализуются JOIN'ы?

Есть для них интерфейсы?

Есть интерфейсы для сложных условий WHERE?

Боюсь, проблема намного сложнее, чем она кажется

-~{}~ 27.04.04 11:41:

Не подходит, этот класс делает слишком много.
Нужна ТОЛЬКО SQL строка на выходе

-~{}~ 27.04.04 11:45:

Вообще есть почти подходящий класс в проекте propel(http://propel.phpdb.org), называется Criteria:

$c = new Criteria();
// Find all authors with first name Karl but
// last name is _not_ Marx.
$c->add(AuthorPeer::FIRST_NAME, "Karl");
$c->add(AuthorPeer::LAST_NAME, "Marx", Criteria::NOT_EQUAL);

Или

$c = new Criteria();
$criterion = $c->getNewCriterion(AuthorPeer::FIRST_NAME, "Leo%", Criteria::LIKE);
$criterion->addOr($c->getNewCriterion(AuthorPeer::FIRST_NAME, "Leonardo", Criteria::NOT_EQUAL));

$c->add($criterion);

Но и этот класс не предоставляет полностью необходимой функциональности, нет полноценной поддержки JOIN и еще много чего....
 

nRay

Guest
Делал кое-что подобное на шаблонах. Если используешь шаблоны, то идея очевидна: несколько sql-шаблонов(заготовок), формируешь данные для них, на выходе - sql. В дальнейшем отказался от такой схемы.
 

nRay

Guest
Оснавная причина в том, что реюз такого кода ничтожно мал(у меня в том проекте), получалось, что почти на каждый запрос пишется свой шаблон и это вполоне логично: универсальный sql, как правило, лишает субд/запрос-зависимых фич . В итоге получаем только то, что в php-коде нет sql-кода, особой выгоды в этом не увидел. Надо заметить, что шаблоны в том случае были XML/XSLT, громодздко как-то.

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

pachanga

Новичок
Часто бывает так, что есть некоторый базовый запрос(обычно это всегда SELECT) в некотором базовом классе.
Так вот потомки, могут расширять этот запрос, добавлять JOIN, условия и т.п.
Делать через строку надоело, т.к. это требуется уже в нескольких местах да и получается очень неудобно
 

AlexVN

Новичок
pacha> Как у тебя реализуются JOIN'ы?
pacha> Есть для них интерфейсы?
pacha> Есть интерфейсы для сложных условий WHERE?
В эту сторону пока не движется - нет большой потребности в этом.
Хотя тоже может быть полезно, т.к. исходная конструкция кода, проверяемая на этапе синтаксического разбора, преобразуется в SQL. Это может сократить время на поиск типа "где же я тут пробел между AND и полем забыл..."
 

pachanga

Новичок
Вот кое-что нашел, по-моему, то, что нужно:

http://opensource.visionp.biz/Query.110.0.html
 
Сверху