С помощью доктрины каковы преимущества использования DQL по сравнению с SQL?
Может ли кто-нибудь предоставить мне пару четких (подтвержденных фактами) причин для использования/изучения DQL по сравнению с SQL, когда требуется пользовательский запрос при работе с классами доктрины?
Я нахожу, что если я не могу использовать встроенную реляционную функциональность ORM для достижения чего-то, я обычно пишу пользовательский метод в классе extended Doctrine или DoctrineTable. В этом методе напишите необходимое в прямом SQL (используя PDO с соответствующими подготовленными инструкциями/защитой от инъекций и т. Д.). DQL выглядит так дополнительный язык для изучения/отладки/обслуживания, который не отображается, предоставляет достаточно веские причины для использования в большинстве распространенных ситуаций. DQL не кажется намного менее сложным, чем SQL, для того, чтобы это оправдывало использование - на самом деле я сомневаюсь, что вы могли бы эффективно использовать DQL, не имея уже твердого понимания SQL. Большинство основных синтаксических портов SQL довольно хорошо сочетаются с наиболее распространенными БД, которые вы будете использовать с PHP.
Что я упускаю/упускаю из виду? Я уверен, что есть причина, но я хотел бы услышать от людей кто намеренно использовал его значительно и какая выгода была от попыток работать с простым ole SQL.
Я не ищу аргумент, поддерживающий ORM, просто DQL, когда нужно сделать что-то, выходящее за рамки основных потребностей типа "получить связь", в традиционной настройке LAMP (с использованием mysql, postgres и т. Д.)
4 answers
Честно говоря, я изучал SQL с помощью Доктрины1.2:) Я даже не знал о внешних ключах, каскадных операциях, сложных функциях, таких как group_concat и многих, многих других вещах. Индексированный поиск также очень приятная и удобная вещь, которая просто работает "из коробки".
DQL намного проще писать и понимать код. Например, этот запрос:
$query = ..... // some query for Categories
->leftJoin("c.Products p")
Он будет выполнять левое соединение между категориями и продуктами, и вам не нужно писать НА p.category_id=c.id .
И если в в будущем вы измените отношение с один-2-много на, скажем, много-2-много, этот же запрос будет работать вообще без каких-либо изменений. Доктрина позаботится об этом. Если бы вы сделали это с помощью SQL, то все запросы пришлось бы изменить, чтобы включить эту промежуточную таблицу "много-2-много".
Я нахожу DQL более читаемым и удобным. Если вы настроите его правильно, вам будет легче объединять объекты, а запросы будет проще писать.
Ваш код будет легко перенести в любую СУБД.
И самое главное, DQL - это язык объектных запросов для вашей объектной модели, а не для вашей реляционной схемы.
Использование DQL помогает вам работать с объектами. в случае вставки в базу данных вы вставите объект
$test = new Test();
$test->attr = 'test';
$test->save();
В случае выбора из базы данных вы выберете массив, а затем сможете заполнить его в своем объекте
public function getTestParam($testParam)
{
$q=Doctrine_Query::create()
->select('t.test_id , t.attr')
->from('Test t ')
$p = $q->execute();
return $p;
}
Вы можете проверить документацию по Доктрине для получения более подробной информации
Ответ Желько довольно точен.
Самая важная причина использовать DQL вместо необработанного SQL (в моей книге): Доктрина отделяет сущность от способа ее сохранения в базе данных, что означает, что сущности не должны изменяться по мере изменения базового хранилища. Это, в свою очередь, означает, что если вы когда-нибудь захотите внести изменения в базовое хранилище (т. Е. Переименовать столбцы, изменить отношения), вам не нужно прикасаться к своему DQL, потому что в DQL вместо этого вы используете свойства сущности (которые могут быть переведены только за кулисами для исправления SQL, в зависимости от ваших текущих сопоставлений).