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