Comments 17
UFO just landed and posted this here
с теоретической точки зрения — все отлично,
с практической — «ебануться» — слишком наворочено а оттуда сложный learning curve — no profit
с практической — «ебануться» — слишком наворочено а оттуда сложный learning curve — no profit
Я думаю, что сказав А, стоит сказать и Б :) Показанная в посте система построения запросов — это пример QBA — «Query By API»:
… запросы конструируются путем использования объектов-запросов, обычно примерно в такой форме:Отсюда
Query q = new Query();
q.From(«PERSON»).Where( new EqualsCriteria(«PERSON.LAST_NAME», «Smith»));
ObjectCollection oc = QueryExecutor.execute(q);
Здесь запрос основывается не на пустом «шаблоне» выбираемого объекта, а на наборе «объектов-запросов», которые совместно используются для определения объекта в стиле команды, предназначенной для выполнения над базой данных. Несколько критериев комбинируется путем использования некоторой конструкции, обычно соединяющей через «And» и «Or» объекты, каждый из которых содержит уникальный объект-критерий, задающий часть условия выборки. К концу запроса могут быть добавлены вызовы объектов фильтрации/манипулирования, такие как «OrderBy(field-name)» или «GroupBy(field-name)». В некоторых случая эти вызовы методов в действительности ведут в объекты, конструируемые программистом и явно связываемые между собой...
Тогда ещё не подумал об этом, а ведь использование шаблнчиков условий будет даже очень удобным да и в целях оптимизации тоже. Но почему-то вместо развития объектного подхода к составлению условий, думаю сейчас в направлении создания текстового описания — а-ля SQL3 :)
Я думаю, что ваш путь с текстовым описанием будет куда сложнее. Оно вам надо? :)
Парсер «синтаксис -> AST», а затем AST-процессор — это не та штука, которую можно написать и забыть — как правило, это одна из самых сложно тестируемых частей. Даже у MS в ее T-SQL встречаются баги разбора SQL-команд.
Куда проще и понятнее Query Objects, которые позволяют строить AST напрямую, пользуясь возможностями самого языка программирования. Понятно, что для сложных запросов этот процесс будет выглядет монстровато, но на практике 90% — более-менее простые запросы.
Далее, Query Object может отлично скрыть за своим API манипуляции нижнего уровня, paging, самостоятельно оптимизировать запросы и т.п.
Я бы сначала пошел таким путем, а затем прикрутил к нему text query, если понадобилось бы, благо одно хорошо уживается с другим. Рекомендую вам посмотреть на HQL и Criteria API из Hibernate.
Тем не менее, решать-то вам :) В любом случае, удачи.
Парсер «синтаксис -> AST», а затем AST-процессор — это не та штука, которую можно написать и забыть — как правило, это одна из самых сложно тестируемых частей. Даже у MS в ее T-SQL встречаются баги разбора SQL-команд.
Куда проще и понятнее Query Objects, которые позволяют строить AST напрямую, пользуясь возможностями самого языка программирования. Понятно, что для сложных запросов этот процесс будет выглядет монстровато, но на практике 90% — более-менее простые запросы.
Далее, Query Object может отлично скрыть за своим API манипуляции нижнего уровня, paging, самостоятельно оптимизировать запросы и т.п.
Я бы сначала пошел таким путем, а затем прикрутил к нему text query, если понадобилось бы, благо одно хорошо уживается с другим. Рекомендую вам посмотреть на HQL и Criteria API из Hibernate.
Тем не менее, решать-то вам :) В любом случае, удачи.
Первый путь уже пройден, разве что только самой оптимизацией его заниматься со стороны его использования и генерации sql.
Я с вами не спорю, делать парсер непросто да и средствами php не эффективно. Но проработав текстовое описание запроса, можно выявить более оптимальный и более гибкий подход к описанию средствами языка программирования. Надеюсь :) Hibernate же через чур мудреный, чтоб с него брать пример.
Я с вами не спорю, делать парсер непросто да и средствами php не эффективно. Но проработав текстовое описание запроса, можно выявить более оптимальный и более гибкий подход к описанию средствами языка программирования. Надеюсь :) Hibernate же через чур мудреный, чтоб с него брать пример.
Как мне кажется, текстовая форма — это только одна из форм, причем не самая удачная (с точки зрения программиста). Хотя ее проработка может быть хорошим «трамплином», чтобы перейти к более общему пониманию формы и механизма запросов в репозиторий объектов.
Второе. В Hibernate есть все, что стоит иметь в хорошем ORM уровня Enterprise :) Совершенно необязательно переносить это все к себе, но кое-что иметь крайне полезно.
К сожалению, обсуждение этого выходит за рамки поста, потому как тут вы поднимали тему исключительно паттерна Query-Object.
Спасибо за предметный разговор.
Второе. В Hibernate есть все, что стоит иметь в хорошем ORM уровня Enterprise :) Совершенно необязательно переносить это все к себе, но кое-что иметь крайне полезно.
К сожалению, обсуждение этого выходит за рамки поста, потому как тут вы поднимали тему исключительно паттерна Query-Object.
Спасибо за предметный разговор.
Не будем разворачивать новых тем, только хочется от вас узнать, на что именно стоит обратить внимание у Hibernate?
HQL — корпоративный стандарт в мире Java (кроме Hibernate, как минимум TopLink и EclipseLink его поддерживают).
На что конкретно вам смотреть, не могу сказать, потому что не очень хорошо представляю, что вы хотите найти; но вот тут в блоге code-inside-out.blogspot.com/2009/01/25-ormapper.html перечислено то, что поддерживается в NHibernate и полезно иметь в ORM.
На что конкретно вам смотреть, не могу сказать, потому что не очень хорошо представляю, что вы хотите найти; но вот тут в блоге code-inside-out.blogspot.com/2009/01/25-ormapper.html перечислено то, что поддерживается в NHibernate и полезно иметь в ORM.
Сорри, отправилось раньше.
Обратите внимание на NHibenrate Criteria API
Обратите внимание на NHibenrate Criteria API
О майн год! Даз ит Битрикс?! %)))
Вы бы эту ссылочку поперёд всего выкатили: multy.sql. Битрикс отдалённо похожие страшилища генерит. Ещё немного подкрутите — будет как там. Универсальность — это конечно здорово. Но, как всегда, с производительностью будет так себе.
Пробема в том, что для крупных сайтов нужна производительность, а для мелких не нужна гибкость. Я до сих пор не понял, на кого рассчитана эта система. Как баловство — очень здорово, логично и мне всё нравится. Но на практике я бы с таким столкнуться не хотел.
Вы бы эту ссылочку поперёд всего выкатили: multy.sql. Битрикс отдалённо похожие страшилища генерит. Ещё немного подкрутите — будет как там. Универсальность — это конечно здорово. Но, как всегда, с производительностью будет так себе.
Пробема в том, что для крупных сайтов нужна производительность, а для мелких не нужна гибкость. Я до сих пор не понял, на кого рассчитана эта система. Как баловство — очень здорово, логично и мне всё нравится. Но на практике я бы с таким столкнуться не хотел.
Про производительность я не спорю, но и не молчу, на форуме всё сказано и предложны варианты оптимизации. На счёт гибкости – не на пустом месте всё создаётся, не было бы этого и подобных проектов, если бы вы (подавляющее большинство) и я не желали бы гибкости в условиях сегодняшнего рынка :)…
При всём этом мною вопросы производительности не забываются.
При всём этом мною вопросы производительности не забываются.
Sign up to leave a comment.
Архитектура CMS. Модель данных. Часть 3