shasoftX 23 янв в 08:32

Построитель SQL запросов на основе мета-информации миграций БД

Простой

8 мин

5.1K

MySQL*PHP*PostgreSQL*SQL*

Туториал

Комментарии 9

leha_gorbunov 23 янв в 09:53

В чём плюсы то перед написанием запроса на SQL?

Поддерживаются 2 БД.
Поддерживаются только запросы, которые и так одинаково выглядят для обеих БД.

Ладно бы там автоматом отлавливались какие-то ньюансы каждой БД, а в построителе код был бы одинаковым.

У меня один вопрос: зачем? (зачем забивать голову знанием о синтаксисе вашего построителя?)

shasoftX 23 янв в 10:02

Возможность КЭШировать выбираемые данные по первичному ключу. Собственно это та самая фишка которая на мой взгляд наиболее полезна. При этом можно писать один код, который будет работать и без КЭШирования. А при его включении сразу сократится количество запросов в БД.
Синтаксис построителя состоит из десятка команд и не представляет трудности для изучения
Для команд DELETE SQL различается. Да, отличия небольшие, но они всё-таки есть

-1

leha_gorbunov 23 янв в 10:35

Ну теперь все понятно. БД же не умеют кэшировать. Ну тогда, конечно, все правильно сделали. Сарказм.

Не представляет трудности для изучения, но зачем я так и не понял.

Я вот даже синтаксического сахара не увидел. Даже букв придется больше печатать по сравнению с SQL.

FanatPHP 23 янв в 11:05

Забавно, что автор сам не понял ответа на этот очевидный вопрос. А нужно затем, что "ORM шагает по планете". И пострители запросов нужны в первую очередь для этих мапперов, чтобы можно было получать объекты сразу из сложных запросов.
А сам по себе, отдельный постритель запросов, действительно смысла имеет очень мало. Ну разве что построение динамических запросов будет вглядеть чуть благообразнее, чем ковыряние в ~~кишках~~ строках.

shasoftX 23 янв в 17:57

Как раз изначально построитель запросов начал писаться чтобы вместо объектов получать именно отдельные поля таблицы с правильно конвертированными значениями PHP<=>SQL. Идея КЭШирования появилась потом. Но, на мой взгляд, эта весьма полезная фича.