-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Какие запросы мешают вам использовать ORM?
- Автор темы bkonst
- Дата начала
Alexandre
PHPПенсионер
практически все сложные запросы упаковываются во вьюверы или хранимые процедуры с параметрами (старайтись использовать такие БД, чтоб они имели эту возможность)
соотношение сложных запросов к простым в моем проекте 4/1
с внедрением вьюверов и хранимых ("сохраненных" кому как нравится, мне привычнее хранимых ....) процедур их кол-во уменьшается до 1/1. Но все же не хотелось бы городить огород из ORM операторов... Наглядность SQL более чем, хотя это дело привычки.
Всего несколько строк, начинающихся со слов CREATE VIEW, ага.
По теме: по-моему попытки построить отображение отношение <=> объект достаточно глупы, пока для ООП у нас вместо математической теории наподобие реляционной алгебры только танцы с бубнами --- "рефакторинг", "паттерны" и т.п. Будет теория --- будет и алгоритм построения отображения, а до тех пор придётся бить в бубен и камлать о пользе ORM.
whirlwind
TDD infected, paranoid
Пойдем дальше... ORM - это не способ выдергивания данных из таблиц. Я здесь уже не раз об этом говорил. Это не значит что нельзя сделать DELETE from bla_table WHERE someexpr. Но это выходит за рамки идеологии. Так как у нас объект - это класс, это подразумевает, что у нас полноценный объект в котором заложена некоторая бизнес логика. Это так же означает, что в моменты onInsert, onUpdate, onDelete и в прочие которых onAfter* onBefore и т.п. может быть заложен алгоритм, который выполняет какие либо действия, что то анализирует и может приняти решение о том, что данный объект не может быть удален, обновлен или в какой либо из этих ситуаций необходимо создать другой объект бизнес логики, удалить другой объект (другого класса) и т.п. Вариантов таких ситуаций может быть неограниченое количество. Нельзя рассматривать просто таблицы в отрыве от бизнес логики. Это неразделимые вещи.
atv
Новичок
whirlwind
Посмотрел http://www.sqlalchemy.org/. Красиво сделано, продуманно, сразу не подкопаешся. Практичность, наверно, тоже достаточно высокая, не попробовав не разберёшся.
Мил человек. Никто не оспаривает необходимость введения абстракций, повышения реюзабельности и т.д. Речь о том, что такая абстракция как ORM не даёт существенного выигрыша, минус накладные расходы. Посмотрите примеры которые вы приводите, чем они абстрактнее SQL, только JOIN-ами и ключами.
Посмотрел http://www.sqlalchemy.org/. Красиво сделано, продуманно, сразу не подкопаешся. Практичность, наверно, тоже достаточно высокая, не попробовав не разберёшся.
whirlwind
TDD infected, paranoid
>Всего несколько строк, начинающихся со слов CREATE VIEW, ага.
ну и чем ваши несколько строк отличаются от наших?
$obj = MetaData::createObject("SomeObject")
MetaData::init($obj);
$obj->setAliases(new MySpecificAliasesForSomeObject());
MetaData::init($obj);
? При этом нас не интересует, поддерживает ли БД такую возможность или нет.
-~{}~ 25.09.06 12:56:
atv не смеши меня по поводу
>Речь о том, что такая абстракция как ORM не даёт существенного выигрыша, минус накладные расходы
я похож на человека, который оперирует исключительно теоретическими выкладками?
ну и чем ваши несколько строк отличаются от наших?
$obj = MetaData::createObject("SomeObject")
MetaData::init($obj);
$obj->setAliases(new MySpecificAliasesForSomeObject());
MetaData::init($obj);
? При этом нас не интересует, поддерживает ли БД такую возможность или нет.
-~{}~ 25.09.06 12:56:
atv не смеши меня по поводу
>Речь о том, что такая абстракция как ORM не даёт существенного выигрыша, минус накладные расходы
я похож на человека, который оперирует исключительно теоретическими выкладками?
whirlwind
TDD infected, paranoid
достаточно весомый и вполне реализуемый
нет ниаких таблиц в 80% бизнес-логики
PHP:
....
protected function _onSave(){
if ( $this->isSendNoticeOnUpdate() ) $this->sendNoticeEmail();
return parent::_onSave();
}
public function getTotalAmount(){
return $this->shipping_method->isSelected()
? $this->shipping_method->cost : parent::getTotalAmount();
}
protected function _onMake(){
$status = new Delivery_Status;
if ( !$status->selectBy("code","wait") )
throw new Exception("Status not found");
$this->set("status",$status);
return parent::_onMake();
}
protected function _onInputBasedOn($operation){
if ( get_class($operation) == "Order" ){
$customer = $operation->get("customer");
$this->set("fname",$customer->get("fname"));
$this->set("lname",$customer->get("lname"));
$this->set("email",$customer->get("email"));
$this->set("address",$customer->get("s_address"));
$this->set("country",$customer->get("s_country")->getCopy());
$this->set("state",$customer->get("s_state")->getCopy());
$this->set("city",$customer->get("s_city"));
$this->set("zip",$customer->get("s_zip"));
$this->set("phone",$customer->get("s_phone"));
$this->set("shipping_method",
$operation->get("shipping_method")->getCopy());
// duplicate lines
$this->deleteLines();
for ( $i = 0; $i < $operation->getNumLines(); $i ++ ){
if ( $operation->selectLine($i) && $this->newLine() ){
$package = $operation->get("product");
$quantity = $operation->get("quantity");
if ( $package->get("f_bundle") ){
$this->addBundlePackages($package,$quantity);
}else{
$this->set("product",$package);
$this->set("quantity",$quantity);
}
}
}
return true;
}
return parent::_onInputBasedOn($operation);
}
function addBundlePackages(Product $bundle,$quantity){
$map = MetaData::createObject("Map.BundlePackage");
$packages = $map->selectRelatedObjects($bundle);
while ( $packages->isSelected() ){
$this->set("product",$packages->getCopy());
$this->set("quantity",$quantity);
if ( !$packages->next() ) break;
$this->newLine();
}
}
...я напомню исходную посылку, ага:
то есть ты согласен, что убогая прокладка в виде ORM не добавляет здесь ничего к функциональности полноценной СУБД?
А что мешает написать триггеры before и after? Дополнительным плюсом будет то очевидное обстоятельство, что залезший грязными руками в базу человек не сможет грубо и цинично надругаться над беззащитной бызыныс логикой, что он сможет проделать в случае использования волшебного ORM.
-~{}~ 25.09.06 13:25:
О чём "разном"? Я тебе пишу, что гениальная "смена алиасов" спокойно реализуется на уровне базы представлениями, совершенно необзяательно что-то ещё городить, а потом хвалиться новой добавленной функциональностью.
То есть ответа по существу не будет --- засчитывать слив?
И ещё вопрос: ты действительно не понимаешь разницы между строгой математической теорией и учением великого гуру Фаулера?
Bermuda
Новичок
bkonst
Отвечая на сабж: никакие не мешают.
QCodo -- ORM во всей красе. В текущем проекте 90% запросов сгенерированы QCodo. 10% которые я писал ручками лишь напоминают мне об ошибках которые заложены в модели данных, моих ошибках, естественно.
PS: Правда автор QCodo не знает, что это ORM называется
Отвечая на сабж: никакие не мешают.
QCodo -- ORM во всей красе. В текущем проекте 90% запросов сгенерированы QCodo. 10% которые я писал ручками лишь напоминают мне об ошибках которые заложены в модели данных, моих ошибках, естественно.
PS: Правда автор QCodo не знает, что это ORM называется
whirlwind
TDD infected, paranoid
Sad Spirit что значит слив засчитан? Начинаем меряться пиписьками? Извини, времени на полноценное соревнование с тобой у меня нет. Могу только приводить в качестве примеров существующий код, по объему и качеству которого можно делать выводы.
Мы тут вообще то про PHP говорим, а не о бредовых идеях типа разнесения алгоритмов по всем запчастям. Ну давай приплетем сюда еще мод реврайт и прочие прибамбасы. А что, неплохой выход - модреврайтом резолвить сервис и редиректить на скрипт, который будет вызывать хранимку. Попахивает извратом, ИМХО.
Мы тут вообще то про PHP говорим, а не о бредовых идеях типа разнесения алгоритмов по всем запчастям. Ну давай приплетем сюда еще мод реврайт и прочие прибамбасы. А что, неплохой выход - модреврайтом резолвить сервис и редиректить на скрипт, который будет вызывать хранимку. Попахивает извратом, ИМХО.
Во, опять понеслась демагогия. Мы говорим о PHP и СУБД, с которой оный PHP работает. Поэтому не очень понятно, почему писать что-то в PHP, который у нас уже есть --- хорошо, а в СУБД, которая, что характерно, у нас тоже уже есть --- плохо. А mod_rewrite уже ты приплёл, исключительно для уведения в сторону дискусии.
Я вон вообще могу подключить PL/PHP и писать на ём процедуры и триггеры. Это будет плохой PHP, а PHP, который у тебя --- хороший?
Так будет ответ по существу или кроме mod_rewrite ещё mod_gzip вспоминать будем?
whirlwind
TDD infected, paranoid
Sad Spirit а я тебе повторю - перечитай топ сначала. Мы говорим о СУБД постольку поскольку это средство
-~{}~ 25.09.06 14:05:
PS Sad Spirit я, применяя так неуважаемый тобой рефакторинг и паттерны, просто подменяю класс DAO и драйвер работы с БД на драйвер работы с XML и мои объекты продолжают прекрасно работать. А что сделаешь ты, в данном случае? Перепишешь половину проекта?
Первоначально идут объекты, которые надо гдето хранить, а не СУБД. Ты что ДЕЙСТВИТЕЛЬНО не можешь понять разницы?
-~{}~ 25.09.06 14:05:
PS Sad Spirit я, применяя так неуважаемый тобой рефакторинг и паттерны, просто подменяю класс DAO и драйвер работы с БД на драйвер работы с XML и мои объекты продолжают прекрасно работать. А что сделаешь ты, в данном случае? Перепишешь половину проекта?