по заказам турдящихся ORM.
Я: - фуфло ваши ORM
1.На предыдущем проекте, были демоны написаны на шеле, ибо пхп долго будет работать(например сканировать рекурсивно директорию, и отбор фалов по критериям и подсчёт мд5 для выбранных - find -type f .... гораздо быстрее, и главное надёжней.)
но надо в базу обращаться. хорошо что у меня небыло орм(было подобие, но не полное) часть логики была прямиком в базе на тригерах и хранимках и заданиях. благодаря этому код на шеле правильно в тупую работая с таблицами, работал.
2 да и в целом, при построении систем, а не сайта пусть даже с миллионной посещаемостью, отдельные части могут делаться на различных языках - просто так лучше. а главное - не все компоненты системы делаются с нуля, часть из них берётся готовые решения и у них свои орм или типа того.
это что, везде дублировать логику?
3 есть интересные вещи(в мускле нету) - что чтение данных и запись данных может ити в разные таблицы(чтение из представления реально идёт) - это делать две модели.. зачем.
4 а главное, зачем отрывать логику от самих данных. мы почему тащимся от ооп
что вместо
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
struct.php
$A = array('a'=>'','b'=>'',....);
$B = '';
$C = 10;
func.php
function a(){return (isset($A['a']))?$A['a']: null;}
....
делаем так
class.php
class Class{
protected $_A = array(...)
....
public function a(){....}
}
зачем мы отрываем логику данных от базы.
вот что за дебил ваще придумал в моделях валидировать уникальность мыла.
типо базе сделать запрос
а мыло васяпупкин есть или нету, а потом сделать инсерт, и ввиду уникальности мыла, один чорт проверить уникальность - это легче чем просто вставить запись, и если ошибка, зная имя ключа_уникального для мыла, понять что мыло не уникально?
зачем в базу мы передаём хеши для паролей..что за мудизм?
вставка пароля - "мой пароль", тригер сам хеширует, используя хранимую функцию - хеш_пароля_юзера
при выборке, выборка идёт из представления - где уже нету поля пароль, оно не читаемо.
при логине, вызывается хранимая процедура(если сесию логина храним в базе ещо лучше)
куда передаёться пароль, база сама=хранимка, пользуясь функцией хранимой хеширующей правильно пароль, сверит , и выдаст либо одного юзера или тру, или ноль юзеров или фолс...
зачем наплевали на процедурное расширение языка sql, triggers, events(jobs), procs(functions, procedures) и лепим орм...
верх лоховства,
отедльным запросом в одной транкзанкции после смена у юзера статуса записывать в таблицу лог о этом изменении.
или при удалении категории, потомков удалять в транкзанкции делая запрос отдельный.
действительно... пускай лок продлится на 300-400 мс дольше при малой скорости передечи другого запроса в базу.
делать сложные запросы которые орм сделать то сделает, но если хочется оптимизировать, начинаются танцы с бубмно, или ORM::byquery('select .....');
============
Я не говорю что понятие модели надо исключить, я не говорю что ОРМ плохо.
я спрашиваю, зачем из базы всю логику перетащили в ОРМ, даже по контролю целостности данных, обновление щётчиков(вставляем юзеру дочерню запись, обновляем счётчик(пре агрегация))
зачем????
