Какие запросы мешают вам использовать ORM?

  • Автор темы Автор темы bkonst
  • Дата начала Дата начала
bkonst не надо лепить монстра. Не заставляйте делать ORM все что не хотите делать сами. Заставляйте его выполнять рутинную работу. Тогда и синтаксис будет нормальным.
 
а можно хотя бы примерное соотношение не сложные/сложные запросы в ваших среднестатистических проектах и собственно 1-2 примера этих самых запросов?
практически все сложные запросы упаковываются во вьюверы или хранимые процедуры с параметрами (старайтись использовать такие БД, чтоб они имели эту возможность)

соотношение сложных запросов к простым в моем проекте 4/1
с внедрением вьюверов и хранимых ("сохраненных" кому как нравится, мне привычнее хранимых ....) процедур их кол-во уменьшается до 1/1. Но все же не хотелось бы городить огород из ORM операторов... Наглядность SQL более чем, хотя это дело привычки.
 
Автор оригинала: whirlwind

При этом следует заметить, что вместе с ORM вы абстрагируетесь от конкретных идентификаторов, которые определены в СУБД, за счет алиасов. Вы запросто можете сменить карту псевдонимов и работать фактически с другой таблицей БД и даже, если так хочется, с другими полями. И это - одной строчкой! Для чего это может понадобиться? На вскидку - обернуть существующую таблицу, которая вам совсем не нравится своим названием или названием своих полей. Еще один пример - создание архивной таблицы (кстати, в целях той же самой пресловутой оптимизации), в которую будут переноситься более старые данные. Не трудно прикинуть, сколько строк надо будет вбить, если все писать native sql.
Всего несколько строк, начинающихся со слов CREATE VIEW, ага.

По теме: по-моему попытки построить отображение отношение <=> объект достаточно глупы, пока для ООП у нас вместо математической теории наподобие реляционной алгебры только танцы с бубнами --- "рефакторинг", "паттерны" и т.п. Будет теория --- будет и алгоритм построения отображения, а до тех пор придётся бить в бубен и камлать о пользе ORM.
 
Пойдем дальше... ORM - это не способ выдергивания данных из таблиц. Я здесь уже не раз об этом говорил. Это не значит что нельзя сделать DELETE from bla_table WHERE someexpr. Но это выходит за рамки идеологии. Так как у нас объект - это класс, это подразумевает, что у нас полноценный объект в котором заложена некоторая бизнес логика. Это так же означает, что в моменты onInsert, onUpdate, onDelete и в прочие которых onAfter* onBefore и т.п. может быть заложен алгоритм, который выполняет какие либо действия, что то анализирует и может приняти решение о том, что данный объект не может быть удален, обновлен или в какой либо из этих ситуаций необходимо создать другой объект бизнес логики, удалить другой объект (другого класса) и т.п. Вариантов таких ситуаций может быть неограниченое количество. Нельзя рассматривать просто таблицы в отрыве от бизнес логики. Это неразделимые вещи.
 
whirlwind
А противники ORM, пишут каждый запрос ручками, независимо от того критична здесь скорость или нет.
Мил человек. Никто не оспаривает необходимость введения абстракций, повышения реюзабельности и т.д. Речь о том, что такая абстракция как ORM не даёт существенного выигрыша, минус накладные расходы. Посмотрите примеры которые вы приводите, чем они абстрактнее SQL, только JOIN-ами и ключами.

Посмотрел http://www.sqlalchemy.org/. Красиво сделано, продуманно, сразу не подкопаешся. Практичность, наверно, тоже достаточно высокая, не попробовав не разберёшся.
 
>Всего несколько строк, начинающихся со слов CREATE VIEW, ага.

ну и чем ваши несколько строк отличаются от наших?

$obj = MetaData::createObject("SomeObject")
MetaData::init($obj);
$obj->setAliases(new MySpecificAliasesForSomeObject());
MetaData::init($obj);

? При этом нас не интересует, поддерживает ли БД такую возможность или нет.

-~{}~ 25.09.06 12:56:

atv не смеши меня по поводу

>Речь о том, что такая абстракция как ORM не даёт существенного выигрыша, минус накладные расходы

я похож на человека, который оперирует исключительно теоретическими выкладками?
 
Это так же означает, что в моменты onInsert, onUpdate, onDelete и в прочие которых onAfter* onBefore и т.п. может быть заложен алгоритм, который выполняет какие либо действия, что то анализирует и может приняти решение о том, что данный объект не может быть удален, обновлен или в какой либо из этих ситуаций необходимо создать другой объект бизнес логики, удалить другой объект (другого класса) и т.п.
А вот это весомый аргумент. Интересно, насколько он реализуемый.
 
достаточно весомый и вполне реализуемый

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();
		}
	}

 ...

нет ниаких таблиц в 80% бизнес-логики
 
Автор оригинала: whirlwind
>Всего несколько строк, начинающихся со слов CREATE VIEW, ага.

ну и чем ваши несколько строк отличаются от наших?

$obj = MetaData::createObject("SomeObject")
MetaData::init($obj);
$obj->setAliases(new MySpecificAliasesForSomeObject());
MetaData::init($obj);

? При этом нас не интересует, поддерживает ли БД такую возможность или нет.
я напомню исходную посылку, ага:
Автор оригинала: whirlwind
При этом следует заметить, что вместе с ORM вы абстрагируетесь от конкретных идентификаторов, которые определены в СУБД, за счет алиасов. Вы запросто можете сменить карту псевдонимов и работать фактически с другой таблицей БД и даже, если так хочется, с другими полями. И это - одной строчкой! Для чего это может понадобиться? На вскидку - обернуть существующую таблицу, которая вам совсем не нравится своим названием или названием своих полей. Еще один пример - создание архивной таблицы (кстати, в целях той же самой пресловутой оптимизации), в которую будут переноситься более старые данные. Не трудно прикинуть, сколько строк надо будет вбить, если все писать native sql.
то есть ты согласен, что убогая прокладка в виде ORM не добавляет здесь ничего к функциональности полноценной СУБД?
 
Sad Spirit эмм... по моему мы о разном.

ЗЫ. Что здесь непонятного и при чем здесь расширение функционала БД? Ты вообще читаешь о чем речь или так просто заскочил на последнюю страницу?
 
Автор оригинала: whirlwind
Это так же означает, что в моменты onInsert, onUpdate, onDelete и в прочие которых onAfter* onBefore и т.п. может быть заложен алгоритм, который выполняет какие либо действия, что то анализирует и может приняти решение о том, что данный объект не может быть удален, обновлен или в какой либо из этих ситуаций необходимо создать другой объект бизнес логики, удалить другой объект (другого класса) и т.п. Вариантов таких ситуаций может быть неограниченое количество. Нельзя рассматривать просто таблицы в отрыве от бизнес логики. Это неразделимые вещи.
А что мешает написать триггеры before и after? Дополнительным плюсом будет то очевидное обстоятельство, что залезший грязными руками в базу человек не сможет грубо и цинично надругаться над беззащитной бызыныс логикой, что он сможет проделать в случае использования волшебного ORM.

-~{}~ 25.09.06 13:25:

Автор оригинала: whirlwind
Sad Spirit эмм... по моему мы о разном.
О чём "разном"? Я тебе пишу, что гениальная "смена алиасов" спокойно реализуется на уровне базы представлениями, совершенно необзяательно что-то ещё городить, а потом хвалиться новой добавленной функциональностью.
 
Автор оригинала: whirlwind
Sad Spirit лично тебе ничто не мешает писать триггеры, если про рефакторинг ты пишешь
только танцы с бубнами --- "рефакторинг", "паттерны" и т.п.
То есть ответа по существу не будет --- засчитывать слив?

И ещё вопрос: ты действительно не понимаешь разницы между строгой математической теорией и учением великого гуру Фаулера?
 
bkonst
Отвечая на сабж: никакие не мешают.
QCodo -- ORM во всей красе. В текущем проекте 90% запросов сгенерированы QCodo. 10% которые я писал ручками лишь напоминают мне об ошибках которые заложены в модели данных, моих ошибках, естественно.
PS: Правда автор QCodo не знает, что это ORM называется :)
 
Sad Spirit что значит слив засчитан? Начинаем меряться пиписьками? Извини, времени на полноценное соревнование с тобой у меня нет. Могу только приводить в качестве примеров существующий код, по объему и качеству которого можно делать выводы.

Мы тут вообще то про PHP говорим, а не о бредовых идеях типа разнесения алгоритмов по всем запчастям. Ну давай приплетем сюда еще мод реврайт и прочие прибамбасы. А что, неплохой выход - модреврайтом резолвить сервис и редиректить на скрипт, который будет вызывать хранимку. Попахивает извратом, ИМХО.
 
Автор оригинала: whirlwind
Мы тут вообще то про PHP говорим, а не о бредовых идеях типа разнесения алгоритмов по всем запчастям. Ну давай приплетем сюда еще мод реврайт и прочие прибамбасы. А что, неплохой выход - модреврайтом резолвить сервис и редиректить на скрипт, который будет вызывать хранимку. Попахивает извратом, ИМХО.
Во, опять понеслась демагогия. Мы говорим о PHP и СУБД, с которой оный PHP работает. Поэтому не очень понятно, почему писать что-то в PHP, который у нас уже есть --- хорошо, а в СУБД, которая, что характерно, у нас тоже уже есть --- плохо. А mod_rewrite уже ты приплёл, исключительно для уведения в сторону дискусии.

Я вон вообще могу подключить PL/PHP и писать на ём процедуры и триггеры. Это будет плохой PHP, а PHP, который у тебя --- хороший?

Так будет ответ по существу или кроме mod_rewrite ещё mod_gzip вспоминать будем?
 
То есть ответа по существу не будет --- засчитывать слив?
1. Не все засунешь в триггеры;
2. Неудобно работать: часть логики в одном месте, часть в другом;
3. Отладка триггеров для многих БД еще тот геморрой.
ЗЫ Как Яндекс нормально заработает могу и ссылками закидать =)
 
Sad Spirit а я тебе повторю - перечитай топ сначала. Мы говорим о СУБД постольку поскольку это средство

ORM не призван облегчить работу с данными. В первую очередь, ORM это способ продлить время существования объектов в соответствии с требованиями алгоритма, а не временем работы программы. Все это имеет значение только в тех программах, где объекты являются элементами бизнес логики. ORM реализует прозрачное извлечение связанных объектов. SQL тут вообще только в качестве средства реализации фигурирует. В качестве механизма продления жизни может быть выбрано все что угодно от Serialize и XML, до РСУБД.
Первоначально идут объекты, которые надо гдето хранить, а не СУБД. Ты что ДЕЙСТВИТЕЛЬНО не можешь понять разницы?

-~{}~ 25.09.06 14:05:

PS Sad Spirit я, применяя так неуважаемый тобой рефакторинг и паттерны, просто подменяю класс DAO и драйвер работы с БД на драйвер работы с XML и мои объекты продолжают прекрасно работать. А что сделаешь ты, в данном случае? Перепишешь половину проекта?
 
Сверху