Psih Когда я смотрел Doctrine, часть примеров из мануала не работали на pgsql, sqlite. Да и штука тяжелая у них вышла :roll:
ну и зачем оно нужно? скуль уже тем прекрасен, что он не привязывается к средству разработки (синтаксис скуеля одинаков и на дельфи, и в пхп). этого достаточно. а уж на этапе проектирования идет выбор именно той базы, которая наиболее подходит под задачу, не вижу смысла делать еще какой то обработчик ради сомнительной возможности работать одинаково как с Интербезом, так и с Клиппером. Зато пальцы во все стороны будут
Тут речь идёт не о том, чтобы сделать универсальный эскуэль, а чтобы минимизировать затраты при переходе с одной СУБД на другую при использовании квери билдера.
Sergey89 По-моему, затраты будут несравнимо меньше, чем затраты на написание такой SQL-обертки. А если вдруг окажется, что перехода на другую СУБД не будет...
угу. А потом для ускорения режима совместимости, запросы будут компилируемые. И их надо будет для оптимизации поправлять ручками. И класть в базу. И давать им id... и вызывать как $sql->do(1251); Шутка это.
При реализации ORM без квери билдера не обойтись Я уже это понял. Независимо от того, будет меняться субд или нет. Сам по себе он удобен, когда надо составить запрос по многим параметрам.
Ti А аргументы где? Я могу все то же самое написать - "отсутствие ORM избавляет программиста от написания большого количества кода, часто однообразного и подверженного ошибкам, тем самым значительно повышая производительность. Кроме того, при необходимости можно жёстко задать код SQL-запросов, который будет использоваться при тех или иных действиях..." и т. д. и т. п. И будет чистая правда. А вот те неприглядные факты, что ORM зачастую приводит к лишним запросам, что код действительно становится однообразным, а ошибки - трудноуловимыми, что в целом производительность не повышается нисколько, а скорость работы проекта из-за кучи в принципе не нужных классов снижается ощутимо - про это приверженцы ORM почему-то не пишут
Dagdamor Никто не говорил что ORM уменьшает время выполнения программы, обычно наоборот. Это один из недостатков ORM. Однако если вам в каком то месте это критично, вы всегда можете спуститься на уровень ниже и написать свой оптимизированный запрос. ORM не приводит к лишним запросам. Максимум, делает запросы не такими оптимизированными как те что вы написали бы руками. Каждый раз вы пишете запрос, вы его выполняете, делаете проверку or die или ей подобную, пробегаетесь по результату. Если вы используете ООП, вам эти данные еще нужно загрузить в объект или, на сохранении, выгрузить из объекта. В сумме этот код достаточно большой, и его часто нужно писать. Сколько запросов в коде вашего проекта? Точно не меньше десяти - обычно десятки, сотни, иногда даже тысячи запросов. Как видите, очень велики шансы допустить в этом месте ошибку. Мы вынесли весь этот код в ORM - протестированную, стабильную библиотеку. Теперь нам меньше нужно писать кода и мы меньше делаем ошибок. P.S. когда копипастите, прочитайте что копипастите
Ti Я-то как раз читал а вы читали? Выделенный курсивом фрагмент как раз больше относится к написанию без ORM, чем с ORM. Видимо, поклонники ORM уже столько раз наступали на грабли генерации неадекватных запросов, что теперь приходится вот так оговариваться а между прочим, необходимость жесткой задачи SQL-запросов при использовании ORM - это прямое признание того факта, что ORM со своими задачами не справляется. Щаз... типичнейшая ситуация при использовании ORM: две таблицы, настроенная связка "один-ко-многим", ты пишешь код, выбирающий основной объект (допустим, тебе нужен только он один), а ORM зачем-то выбирает все связанные объекты тоже, расходуя не только запросы, но и память, когда это совершенно не нужно. Как бы разработчики ORM не кричали, что у них все учтено и дергается только то, что действительно нужно, подобные ситуации всплывают регулярно. Кроме того, у новичков иногда при использовании ORM получаются не то, что "неоптимизированные" запросы, а просто тихий ужас (десятки запросов в ситуации, когда достаточно одного-двух). Как такое найти и исправить? Правильно, смотреть логи SQL и чинить ручками, ручками
Ti Да что вы? А еще мы каждый раз делаем запросы к мускулу через сокеты, глупые все это - проверка результата на корректность, фетчинг результата и т. д. - запросто выносится в отдельный функционал и параметризуется, не надо считать себя Колумбами. Тем более что к ORM это не имеет никакого отношения. Использовать ORM, только чтобы кто-то за тебя фетчил результат, запихивал его в поля объектов и разбрасывал по элементам массива, это детский сад. Сравните сами: Вариант без ORM PHP: <?php $players=$db->query("SELECT p.*, b.* FROM players p, bands b WHERE p.id IN (10,15,17,20) AND p.bandid=b.id ORDER BY p.name"); Вариант с ORM PHP: <?php Query::select('[p.*], [b.*]') ->from(array('players' => 'p')) ->join(array('bands' => 'b'), '[p.bandid] = [b.id]') ->whereIn('[p.id]', array(10, 15, 17, 20)) ->orderBy('[p.name]'); Где больше шансы допустить ошибку? Sergey89 ORM - это и есть реализация. Чистая и непорочная идея вряд ли кому нужна а у всех существующих реализаций, без исключения, есть свои тараканы.
Факты говорят обратное: в здоровом проекте мы написали 2 SQL запроса, и то из-за не совершенства той реализации ORM - сейчас их 0 связанный объект подгружается однократно и только при обращении к этому свойству объекта Взят конечный запрос, нет внешних параметров, нет экранизации, а все это код раздувает. Это не ORM а QueryBuilder Написать универсальную функцию под это дело не выйдет - слишком много параметров. У ORM три основные задачи: - сохранить объект в базу - удалить объект из базы - получить объекты из базы Если вы считаете это детским садом я очень рад что все так просто.
PHP: <?php $players=$db->query("SELECT p.*, b.* FROM players p, bands b WHERE p.id IN (10,15,17,20) AND p.bandid=b.id ORDER BY p.name"); Случай, когда используется универсальный findAll: PHP: <?php $players = $pm->findAll(array('sort' => 'name', 'criteria' => 'id IN (10, 15, 17, 20)'))); Случай, когда используется метод поиска по конкретному полю: PHP: <?php $players = $pm->findByIds(array(10, 15, 17, 20), array('sort' => 'name'));
На время забыл про эту тему. Но покопав hibernate опять возобновил работу. Оригинальный запрос: [sql]SELECT (TO_DAYS(NOW()) - TO_DAYS(album.post_date)) AS date_diff, album.album_name, artist.name AS artist_name, album.album_photo, album.album_info, album.id AS album_id, artist.id AS artist_id FROM album, artist WHERE album.artist_id = artist.id ORDER BY album.post_date DESC LIMIT 5[/sql] Объектный запрос: PHP: <?php $query = new SelectQuery(); $query ->get( Expression::sub( SQLFunction::create('TO_DAYS', SQLFunction::create('NOW')), SQLFunction::create('TO_DAYS', SQLField::create('album.post_date')) ), 'date_diff' ) ->get('album.album_name') ->get('artist.name', 'artist_name') ->get('album.album_photo') ->get('album.album_info') ->get('album.id', 'album_id') ->get('artist.id', 'artist_id') ->from('album') ->join( SQLJoin::inner('artist', Expression::eqField('album.artist_id', 'artist.id')) ) ->orderBy( SQLOrder::desc('album.post_date') ) ->limit(5); Результат: [sql]SELECT (TO_DAYS(NOW()) - TO_DAYS(`album`.`post_date`)) AS `date_diff`, `album`.`album_name`, `artist`.`name` AS `artist_name`, `album`.`album_photo`, `album`.`album_info`, `album`.`id` AS `album_id`, `artist`.`id` AS `artist_id` FROM `album` INNER JOIN `artist` ON (`album`.`artist_id` = `artist`.`id`) ORDER BY `album`.`post_date` DESC LIMIT 5[/sql]
Sergey89, у вас правильно построено мышление. Вот только форумом ошиблись - тут в основном "зачем нам эта абстрация" тусят.
MiksIr Угу, особенно когда нет никакой абстракции, а запрос выглядит как чистой воды обертка над SQL Sergey89 Ты по сути тот же самый запрос излагаешь при помощи других инструкций. В этом нет смысла, имхо, просто получится еще один "птичий язык". Почему бы не подойти с другой стороны к проблеме?
Dagdamor +100 Не вижу смысла изобретать свой SQL, причём не редко то что выходит, становится куда более сложным чем оригинальный.
Да, "другая сторона" - это потом реплейсить кучу sql инструкций только потому, что было LIMIT 1,10 а стало LIMIT 10 OFFSET 1. Ну да, в любимом редакторе есть поиск и замена, не спорю. Хех.
А насчет цитаты... она тут не к месту, ибо речь идет не о объектном подходе для хранения данных, а о банальной абстракции в виде объекта. Класс БД у вас, надеюсь, в виде объекта, ага?...
Часто вы переезжаете на другую Субд ? (Если один из десятков проектов за всю жизнь придётся переводить то уж можно и потрудиться, выйдет всё равно дешевле чем заранее писать под десяток разных Субд 8 из которых никогда не будут нужны)