- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
public function getId($model=0){
if($model->catalog_id){
return $model->catalog_id;
}else{
$L=Yii::app()->db->createCommand()
->select($this->tableName().'_id')
->from($this->tableName())
->order($this->tableName().'_id DESC')
->limit(1)
->queryRow();
return ($L[$this->tableName().'_id']+1);
}
}
Follow us!
АЗАЗАЗЗАЗАЗАЗА
----------------------------------------
Вот расчехлят все юзерскрипт, который не показывает комменты людей из указанного списка (например ['Horse2']), и убирает оценки (где-то тут такой уже проскакивал)... И тебя просто не станет ;)
Ну я бы не был так категоричен. У таких штук composability получше, чем у текстовых запросов (если, конечно, орм путёвый): легко добавлять джойны и дополнительные where в зависимости от каких-то условий. Ну и ->where('name = ?', $name) тоже удобней, чем $sql .= 'name = ?'; $params[] = $name; ;)
Ну и плюс ко всему у ORM'ов бывают и другие фишки. Например кеширование (для PHP, имхо, не особо актуально), удобная работа с foreign keys и ассоциативными табличками ($user->groups против джвух рукописных джойнов) и т.п.
Я думал, ты что-то из себя представляешь, но оказывается ты - полный отстой. Буду хардкорно минусовать.
p/s/
Постить пустые экраны, гоатсе, односложные фразы типа "отсосу кавказцу" и тп - это ты считаешь достойным пацана? Тогда ты сам петух.
Обычный запрос закэшируется не хуже. Всё равно придётся делать синтаксический разбор.
bind_param отработает аналогично, один в один.
Какой-то псевдоязык из птичьих, честное слово.
Ну если запрос составляется на последнем этапе, то почему нет?
> Обычный запрос закэшируется не хуже
Не запросов. Результатов.
> bind_param отработает аналогично, один в один.
Писать больше.
> Какой-то псевдоязык из птичьих, честное слово.
За запись в духе user.groups (many-to-many отношение) и file.owner (many-to-one) той же SQLAlchemy, имхо, можно продать душу дьяволу и смириться с птичьим языком. Главное вспомнить, сколько нужно написать для работы с many-to-many на голом SQL :)
это печально
> @bormand: сколько нужно написать для many-to-many
и сколько?либо
зы. видел я выхлоп того, что в итоге генерит, например, hibernate
там тоже можно аннотациями расставить many-to-many, many-to-one
не очень оптимально
> не очень оптимально
А тут спорить не буду. Но для примитивных задач типа "отредактировать группы юзера" орм вполне удобен. А в таких задачах производительность не особо важна.
но вовсе не из-за того, что на sql стираются пальцы в кровищщу
это дорога в ад
Я за подход с конструкторами запросов (встроенных мини-дсл).
Во-первых, это позволяет подключить компилятор к валидации запросов, выявляя некоторые ошибки до запуска программы.
Во-вторых, упрощает анализ кода. Не нужно думать, все ли скобочки и запятые расставлены правильно после конкатенации частей запроса.
Но я против ORM.
Почему?
Explicit is better than implicit.
Я как-то половину новогодних праздников искал ошибку в коде, вызванную тем, что люди плохо представляют себе, что именно ORM делает за них.
Слишком неочевидны границы транзакций и кол-во обращений к базе.
Ну и на проблемы с производительностью наталкивались серьёзные. Которые вообще непонятно, как чинить.
Сейчас приходится работать с крупным java-проектом (750.000 loc), в котором не используется ORM. Какое счастье, что его там нет, иначе в сорцах было бы вообще не разобраться, особенно с учётом обилия датасорсов.
В той же алхимии вполне очевидны.
> кол-во обращений к базе
> Ну и на проблемы с производительностью наталкивались серьёзные
А тут согласен.
Значит мой хитрый план работает.
Обосрать самого себя, раскачать ситуацию, чтобы народ сам отказался от демократии и захотел Империю