Конструктор SQL-запросов

[[sid]]

robocomp
StUV
Спасибо, вы подтвердили мои предположения! Это решение не самое оптимальное по соотношению цена качество! Для реальных приложений гораздо проще использовать PlainSQL.

robocomp
Да запустились программеры, совсем не знают реляционной теории!

 

[pachanga]

Re: Конструктор SQL-запросов

Автор оригинала: [sid]
Существует решение, которое называется конструктор SQL-запросов (QueryObject по Фаулеру). Основная идея в генерации SQL кода с помощью объекта.

Посмотри исходники Hibernate, в PHP пока ничего подобного нет, и хотя мы пытаемся нечто похожее привить в LIMB, в любом случае до HQL будет очень далеко...

 

[Voxus]

Re: Re: Конструктор SQL-запросов

Автор оригинала: pachanga
в PHP пока ничего подобного нет

есть.

onPHP's OSQL

 

[.des.]

Voxus, простите, но onPHP's OSQL и Hibernate сравнивать просто невозможно.

 

[Voxus]

Автор оригинала: .des.
Voxus, простите, но onPHP's OSQL и Hibernate сравнивать просто невозможно.

а их и не нужно сравнивать. пока у php не появится полноценный memory management, а следом за ним и application server, - позволить себе динамические мэппинги мы не сможем (слишком ресурсоемко).

а вот из xml-схемы а-ля hibernate mapping генерить бизнес-объекты и соответствующие DAO-классы - легко.

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

 

[pachanga]

Автор оригинала: Voxus
а их и не нужно сравнивать.

Сравнивать конечно не нужно, но можно заимствовать и адаптировать

а вот из xml-схемы а-ля hibernate mapping генерить бизнес-объекты и соответствующие DAO-классы - легко.

Насчет генерации кода бизнес объектов я не согласен - это зло. Просто невозможно сгенерить частную логику.

Можно конечно, генерить базовые классы бизнес модели, а от них наследовать конкретные, как это делает Propel, но мне такой подход совсем не нравится.

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

А вот генерить мапперы(или как сказано выше DAO), при условии, что эти нагенеренные мапперы не будут вообще правиться вручную, это как раз возможно. Естественно, бизнес модель при этом скорее всего будет иметь определенные некритические ограничения, т.к. сделать полноценный маппинг ala Hibernate довольно трудоемко.

 

[Voxus]

Автор оригинала: pachanga
Насчет генерации кода бизнес объектов я не согласен - это зло.

речь не идет о генерации бизнес-логики. в самом примитивном случае это может выглядеть вот так:

class BasePerson {пропертя с дефолтами/геттеры/тайпхинтнутые сеттеры};
class Person extends BasePerson {а вот тут пусто и руками пишется бизнес-логика, if any};

генериться только BasePerson.

 

[pachanga]

Автор оригинала: Voxus
речь не идет о генерации бизнес-логики. в самом примитивном случае это может выглядеть вот так:

class BasePerson {пропертя с дефолтами/геттеры/тайпхинтнутые сеттеры};
class Person extends BasePerson {а вот тут пусто и руками пишется бизнес-логика, if any};

генериться только BasePerson.

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

-~{}~ 26.07.05 12:37:

Автор оригинала: Voxus
а их и не нужно сравнивать. пока у php не появится полноценный memory management, а следом за ним и application server, - позволить себе динамические мэппинги мы не сможем (слишком ресурсоемко).

Кстати, по-моему мы здесь несколько ушли от темы, т.к изначально требовался всего лишь конструктор SQL запросов, а не конструктор объектных запросов

 

[Voxus]

Автор оригинала: pachanga
Я об этом и говорил, именно так поступает Propel, но как раз в этом я и вижу источник проблем. Как только меняется схема маппинга должен измениться базовый класс, что может привести к несоответствию реализации наследуемого класса. Я не вижу ничего хорошего, когда такие изменения происходят где-то за кулисами.

на практике - редко бизнес-классы и/или схема БД меняются настолько, что изменения потом долго проносить по всем "уровням" приложения.

тем более - "за кулисами" ничего не происходит: программист сам вносит изменения в схему БД, сам вносит изменения в мэппинг, сам сверяет "базовый" бизнес-объект и наследников от него.

от этого никуда не дется в любом случае, поэтому никто ничего от программиста и не прячет.

Кстати, по-моему мы здесь несколько ушли от темы, т.к изначально требовался всего лишь конструктор SQL запросов, а не конструктор объектных запросов

ну да, я ссылкой на первый вопрос отвечал.

 

[pachanga]

Автор оригинала: Voxus
на практике - редко бизнес-классы и/или схема БД меняются настолько, что изменения потом долго проносить по всем "уровням" приложения.

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

 

[Voxus]

Автор оригинала: pachanga
Я бы даже его не хранил под CVS

common practice. ;-)

 

[lyxsus]

явно не в тему, но тут мне пришел интересный линк:
http://www.phpclasses.org/browse/package/2449.html

 

[Voxus]

а можно куда-нибудь выложить тарболл для незарегистрированных там?

 

[lyxsus]

http://www.lyxsus.ru/bullets/mysql_translator-2005-08-02.zip
(взято с http://www.phpclasses.org/browse/package/2449.html)

 

[Voxus]

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

а уж как по-русски могут завернуть запрос и как его преобразовывать потом.. ;-)

 

[lyxsus]

прикольно было бы сделать запрос типа:
"Поменяй значение там-то и там-то на то-то и то-то, а в дргуой таблице зависимые поля удали. И пошли пить пиво..."

 

[Voxus]

а программисты тогда зачем?

 

[lyxsus]

большинство клиентов даже такой запрос не осилят.

 

[insa]

Шальная мысля - а может как с i18n сделать ?
Наклепать файлов в духе:

mysql.inc.php:
$query[1] = "SELECT %s FROM %s LIMIT 1,2"

pgsql.inc.php:
$query[1] = "SELECT %s FROM %s LIMIT 1 OFFSET 2"
ну итд... а там их через printf или str_replace...

Как появляется действительно сложный запрос - писать его для n баз данных в эти "словари" запросов, а для простых запросов использовать простые query билдеры.

==> расширить стандартые инструменты возможностью выбокри из словарей...

 

[Sherman]

Кстати, в ms sql server уже давно есть механизм English Queries, при всей его оригинальности, он представляет чисто академический интерес