парсер для SQL

[Absinthe]

WMix в хайлоадах не работал, но неоднократно читал, что там не бывает сложных запросов.

В этой же теме произошла путаница: некоторые говорят про производительность написания, некоторые про производительность выполнения.

 

[Тугай]

Насколько я понмаю замысел в том, что было бы очень круто иметь для билдера конструктор из строки SQL, который бы можно было модифицировать после.
Билдер, имхо, решает две проблемы(задачи):
1. Переносимость между разными субд.
2. Чистота кода при формировании запроса.

Я это вижу, как какой-то билдер с шаблонами, хотя до реализации от идеи пока далеко, и перносимость между субд здесь мешает очень сильно, занимая человеческую оперативную память.

 

[С.]

Билдер, имхо, решает две проблемы(задачи):
1. Переносимость между разными субд.
2. Чистота кода при формировании запроса.

Два очередных вульгарных мифа, упорно повторяемые сугубыми "теоретиками".

 

[Вурдалак]

Два очередных вульгарных мифа, упорно повторяемые сугубыми "теоретиками".

https://github.com/FriendsOfSymfony/FOSUserBundle — а ты видишь где-то здесь требование «MySQL only» или похожее?

 

[Тугай]

С.
Нужно смотреть и с другой стороны, никто (имееются ввиду разаработчики фреймворокв и/или орм) сегодня не пишет билдер под конкретную субд. Все более менее известные разработчики делают их универсальными.
В реальном проекте естественно никто не прыгает с одной бд на другую. Но это другой вопрос. Переносимость - это не значит, что я должен думать как писать перносимые запросы, а как раз наоборот я могу об этом не сильно задумыааться работая с одной единственной бд.
Переносимость должна автоматом получаться.

Насчет чистоты, с билдером отпадают хотя бы такие "вопросы" в какой строке ставить . или and/оr, когда собираешь из строк где пробел добавлять перед from where или в предыдущей строке и т.д.
С билдером исчезает проблема со стилем написания, хотя бы это уже добавляет чистоты.

 

[Sad Spirit]

поговаривают, что порою два простых запроса работают быстрее чем один сложный.

Поговаривают, что кроме MySQL и его 15 форков бывают и СУБД с нормальным оптимизатором.

В этой же теме произошла путаница: некоторые говорят про производительность написания, некоторые про производительность выполнения.

А некоторые, в частности ТС, про производительность вообще изначально не говорили. Но похапэ-погромисты, со свойственным им кругозором опять всё свели "на баб".

Что касается переносимости и т.п., то в принципе через преобразование AST задачка решаемая, хотя и сложная. Но у меня пока идея попроще: обрабатывать исключительно диалект Postgres'а.

Парсер решил в результате писать руками по мотивам Doctrine'овского для DQL: грамматика для php-peg получается уж больно страшная, да и работать будет вряд ли правильно из-за некоторых особенностей.

 

[С.]

Тут дело не только в производительности. Наличие всей этой супер-пупер универсальной прокладки для модели данных крайне сомнительно. Между конкретной моделью данных приложения и хранилищем достаточно простого драйвера, который пишется при необходимости в полчаса под любой SQL дилаект и вобще произвольный способ хранения.

 

[Sad Spirit]

Тут дело не только в производительности. Наличие всей этой супер-пупер универсальной прокладки для модели данных крайне сомнительно. Между конкретной моделью данных приложения и хранилищем достаточно простого драйвера, который пишется при необходимости в полчаса под любой SQL дилаект и вобще произвольный способ хранения.

Хочу ещё раз уточнить: я-то никакую "супер-пупер универсальную прокладку" писать не планирую, за этим проходите к авторам Doctrine. Я пока планирую сделать билдер для конкретного диалекта SQL, а для того, чтобы им было --- лично мне --- удобнее пользоваться, добавить в него возможность разбора [фрагментов] запроса.

В приличном билдере (билдер из одного класса с массивчиками за приличный не прокатит, это обсуждалось уже в теме, ссылка на которую есть в первом сообщении) всё равно для запроса придётся строить дерево.

 

[С.]

Даже "удобный" билдер здесь лишняя прокладака. Для написания приложение эти "удобства" не нужны, поскольку оно вообще говоря не должно знать, где хранятся его данные (тем более с каким диалектом там SQL). А для написания драйвера (который как бы уже не часть бизнес-модели), можно и без "удобств" обойтись, и наоборот на оверхеде съэкономить не грех.

Всякого рода билдеры свойственны охапэ-погромистам, кругозор котрых никак не может отделить модель данных приложения от хранилища. Вот они придумывают всякие "удобства".

 

[Sad Spirit]

Для написания приложение эти "удобства" не нужны, поскольку оно вообще говоря не должно знать, где хранятся его данные (тем более с каким диалектом там SQL).

Спорим с соломенным чучелком? Тут кто-то --- кроме тебя --- говорил про использование билдера в "приложении", а не в слое работы с базой?

А для написания драйвера (который как бы уже не часть бизнес-модели), можно и без "удобств" обойтись, и наоборот на оверхеде съэкономить не грех.

Пробовал, не понравилось, хочу оверхед. Как уже было сказано выше, он легко побивается кэшированием результата генерации, как в тех же шаблонизаторах, вот это вот жалкое

Но-но, не надо тут широкими жестами риторически сравнивать вывод данных и выборку данных из базы.

за возражение, на мой взгляд, не катит.

Всякого рода билдеры свойственны охапэ-погромистам, кругозор котрых никак не может отделить модель данных приложения от хранилища. Вот они придумывают всякие "удобства".

Ну да, у правильных похапэ погромистов зато приложение работает одинаково хорошо и с данными в СУБД, и с данными в XML файлах, и с данными в подготовленном секретаршей Excel'е, ибо "приложение не должно знать, где хранятся его данные", всё решается заменой простого драйвера, написанного "в полчаса под любой SQL дилаект и вобще произвольный способ хранения".

Ох уж эти сказочки, ох уж эти сказочники. Особенно про "полчаса", конечно, понравилось.

 

[WMix]

Sad Spirit
меня смущает парсер известного языка. я понимаю когда создают свой язык (решающий ту или иную проблему) который после компиляции создаст известный язык.

 

[С.]

В любом проекте есть прикладные и есть системные части. Я не понимаю, почему к ним нельзя относиться по-разному -- на высоком уровне и с "удобствами" в одном случае, и с точки зрения производительности в другом. Даже если обе части пишутся на одном языке. Почему-то наблюдается однобокоий крен в ту или иную сторону. Либо "удобства" везде (оверхед закешируем), либо выложьте и подайте нам строгую типизацию.

 

[Sad Spirit]

::грустно глядя на файл Parser.php в две тыщи строк::
В общем есть некий большой промежуточный финиш, удалось справиться с продукцией a_expr из грамматики Postgres'а. Учитывая, что, например, WHERE там задаётся как

where_clause:
			WHERE a_expr							{ $$ = $2; }
			| /*EMPTY*/								{ $$ = NULL; }
		;

аналогично и HAVING, а в списке полей SELECT и в ORDER BY с GROUP BY только чуть накручено вокруг a_expr, то из интересного остался разбор FROM и WINDOW.

Сделано рекурсивным спуском, без возврата.

Наверное выложу потом когда-нибудь эту красоту на какой-нить гитхаб.