Как я перестал писать SQL-запросы для менеджеров: Концепция «Isolated SQL Generator»
Предыстория: Эндпоинт, который не кончается
Каждый разработчик проходил через это. У вас есть проект, база данных и отдел маркетинга или аналитики. Сначала они просят: «А выгрузи нам список юзеров из Ташкента?». Ты пишешь метод в репозитории, делаешь эндпоинт. На завтра: «А добавь туда дату последнего заказа». Еще через день: «А можно только тех, кто потратил больше 100 баксов?».
В итоге твой репозиторий превращается в кладбище методов типа getUsersWithOrdersByRegionAndAmount(). Ты тратишь время не на фичи, а на обслуживание хотелок, которые меняются каждый час.
Я решил, что пора это менять. Но давать ИИ прямой доступ к базе — это безумие. Так появилась концепция моей библиотеки.
Концепция: ИИ как архитектор, а не администратор
Основная проблема существующих решений — они пытаются быть «умными агентами». Вы даете им доступ к БД, и они сами там что-то ковыряют. Это небезопасно, медленно и страшно.
Моя библиотека строится на пяти тезисах:
1. Zero DB Access (Полная изоляция)
Библиотека физически не имеет доступа к вашей базе данных. В ней нет конфига DB_PASSWORD. Она работает только с теми данными (схемой таблиц), которые вы сами решите ей передать. Для нейросети это выглядит так: «Вот структура, представь, что ты аналитик, напиши запрос».
2. Генерация вместо выполнения
Либа не делает DB::query(). Она генерирует чистый, отформатированный SQL и отдает его вам в виде строки. Дальше выбор за вами:
- Выполнить его сразу.
- Отправить на проверку администратору.
- Просто вывести в дебаг-панель.Вы сохраняете контроль над точкой входа в БД.
3. Экономия токенов (Context Pruning)
Отправлять всю схему БД (50+ таблиц) на каждый запрос — это дорого и глупо. Либа позволяет передавать только нужный контекст. Мы не кормим Gemini лишней информацией, экономя деньги и увеличивая точность ответа.
4. Встроенный «Вышибала»
Даже если ИИ «галлюцинирует» или пользователь пытается через промпт заставить его удалить базу, на стороне PHP стоит жесткий фильтр.
- Никаких DROP, DELETE или TRUNCATE.
- Запрет на Multi-query (двойные запросы через ;).
- Только Read-only команды.Если запрос не прошел валидацию — он никогда не дойдет до вашего SQL-драйвера.
5. Zero-API Workflow
Вместо того чтобы плодить методы в коде, вы создаете один интерфейс. Менеджер пишет: «Кто из клиентов купил больше всего курсов в январе?», и либа на лету генерирует правильный JOIN с агрегацией.
Мы привыкли, что ИИ — это либо чат-бот, либо автодополнение кода. Но настоящая мощь начинается там, где ИИ становится умным интерфейсом к данным.
С этой библиотекой я перестал быть «человеком-запросом» для отдела продаж. Теперь они могут сами формулировать вопросы, а я лишь слежу за тем, чтобы сгенерированный SQL был оптимальным.
А как вы решаете проблему бесконечных выгрузок? Доверили бы генерацию SQL нейронке, если бы выполнение оставалось под вашим контролем?
Попробуйте сами
Библиотека сейчас в активной разработке. Буду рад фидбеку от тех, кто устал писать SELECT * FROM... по десять раз на дню.
[Ссылка на ваш GitHub]