Изменения

Funq - Funq — концепция околофункционального, гибкого язык запросов к реляционным базам данных, чем-то похожего на LINQ и призванного заменить SQL для разработчиков, к тому же, скрывая диалекты, свойственные отдельным СУБД.

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

Таким образом, было бы неплохо создать ''не SQL-подобный'' язык запросов, который был бы к тому же элегантен и удобен для использования в клиентских приложениях. Например, можно максимально приблизить формирование запросов к заданию выражения над таблицами, как алгебраическими объектами, с использованием различных операций реляционного исчисления - исчисления — JOIN-ов, ограничений, проекций и т.д, а также других нереляционных преобразований - преобразований — они необходимы потому, что возможностей построения запросов разработчики различных СУБД создали великое множество, а на замену SQL годится по меньшей мере равномощный ему язык. Сразу оговоримся, что основные проблемы написания запросов к базам данных связаны с запросами выборки. Запросы удаления/обновления часто используют базу просто как хеш-таблицу, а запросы вставки и [[wikipedia:DDL|DDL]]-запросы просто имеют достаточно бедный синтаксис. Их также нужно реализовать, как часть языка запросов, но основной интерес представляют запросы выборки. Ими-то мы в первую очередь и займёмся.

Например, рассмотрим вот такой SQL-запрос. Можно заметить, что это не чистый SQL - SQL — здесь ещё присутствуют подстановки имён таблиц из хеша <code>$t</code> и имён полей <code>$child</code> и <code>$parent</code>.

Вообще-то, внезапно можно осознать, что <code>relation.something().something().something() - </code> — функциональный стиль программирования, а точнее, что это очень похоже на [http://www.martinfowler.com/bliki/FluentInterface.html Fluent Interfaces]. Собственно, они и сами являются пародией на ФП, хотя и довольно жалкой.

Кроме того, можно вспомнить язык [http://msdn.microsoft.com/en-us/netframework/aa904594.aspx LINQ] (Language INtegrated Query) от Microsoft. Если в LINQ пользоваться только объектным стилем задания запроса, то LINQ тоже станет похож на Funq. Другое дело, что на практике делать именно так в LINQ практически невозможно и в любом случае неудобно. Важно также, что и цель у создателей LINQ изначально была другая - другая — встроить язык запросов в .NET с помощью обычных его средств и научить языки .NET работать через одни и те же классы и интерфейсы с базами данных, XML-файлами, да и вообще любыми источниками данных, вплоть до обычных массивов.

А ещё, раз уж мы вспомнили про LINQ, можно сразу заметить, что описанная идея позволяет легко реализовать "язык запросов" «язык запросов» на объектном интерфейсе в родном синтаксисе многих языков программирования. Конкретно автора (меня - меня — ~~~~) интересует язык [[Perl]], он-то и будет рассмотрен в данной статье.

Нужно отметить, что формирование запроса в родном синтаксисе языка имеет и недостаток - недостаток — затруднение кэширования скомпилированных запросов. Из-за этого может пострадать производительность; однако, если объекты запросов кэшируются самим приложением, этого не произойдёт. Этот недостаток говорит нам о том, что имеет смысл реализовать одновременно и объектный подход к формированию запроса, и просто трансляцию из Funq-кода.

* Автоматическая трансляция имён таблиц, и вообще запросов к таблицам. Это значит, что всегда можно переопределить <source lang="perl">$dbh->query("some_table")</source> так, что на самом деле этот конструктор будет возвращать не новый, девственно чистый, объект запроса к таблице some_table, а некоторый другой объект запроса - запроса — с заданными дополнительными ограничениями, к другой таблице, или вообще результат сложного запроса (хотя так делать, наверное, не надо). То есть, по сути, "программные представления"«программные представления».* Именованные параметры (placeholder'ыplaceholder’ы) -  — задаются как '''<code>?name''' - </code> — и автоматическое определение имени из контекста в простых выражениях. Например, параметр из условия '''<code>config=?''' </code> будет, очевидно, называться ''<code>config''</code>, если только уже не задан другой параметр с таким именем. Кроме того, один и тот же явно именованный параметр можно использовать в различных местах выражения и даже в разных операторах в процессе формирования запроса.* Персонализация условий заданием имени таблицы (или имён таблиц) -  — к примеру, если в запросе записано условие <code>exif.?placeholder</code>, а значение placeholder-а равняется <code>.file=? and .config=?</code>, то в запрос будет подставлено преобразованное условие <code>exif.file=? and exif.config=?</code>. Если аналогично требуется сделать для нескольких таблиц (ситуация редкая), синтаксис усложняется - усложняется — теперь условие в запросе, например, может звучать как <code>[exif, configs].?placeholder</code>, а в placeholder-е, например, как <code>_1.file=? and _1.config=_2.id</code>. При этом _1 будет заменено на имя первой таблицы, _2 - _2 — на имя второй, и так далее.* Наличие хинта (подсказки) для последовательного выполнения подзапросов, т.е. то есть выполнения сначала внутреннего запроса, а потом внешнего.* Автоматическое кэширование компилируемых из Funq-кода (т.е. то есть **не** формируемых объектно) запросов. Кэширование детализированных условиями и порядками сортировки/группировки запросов. Следует отметить, что если в процессе выполнения появляется слишком много (неограниченное относительно вариации входных данных количество) детализированных условиями и порядками запросов, значит, что-то //"Defective «Defective By Design"Design»//, а точнее, кто-то забыл про placeholder'ы...placeholder’ы…

* Собственно работающий компилятор запросов ;) начал с MySQL. Компилятор с полной поддержкой синтаксиса SELECT, с корректной оптимизацией / добавлением подзапросов, разрешением спорных ситуаций по семантике, поддержкой хинтов типа CALC_FOUND_ROWS, SQL_CACHE и ти т.п п., заменой имён таблиц и прочими;

* "Аппликация" «Аппликация» имён таблиц к выражениям (замена `_` на имя нужной таблицы при подстановке выражения вместо `table`.?expression;

* Удобные функции получения результатов запросов (в основном аналогично DBI): успешность выполнения / массив хешей / массив разделённых хешей / массив массивов / хеш хешей / одна строка / одно значение. Или ручками - ручками — тоже можно.* Разделение функционала на "ядро" «ядро» и "драйверы"«драйверы»;

- — Автоматической генерации алиасов например для подзапросов, если они не задаются явно;- — Поддержки подстановки хешей в текст запроса (например в виде field=value AND field=value);- — Возможности программного последовательного выполнения подзапросов - подзапросов — сначала внутреннего, а потом внешнего, с программной передачей результата первого во второй (в MySQL бывают ситуации когда это ускоряет запрос В РАЗЫ);- — Нет ORM'аORM’а, и даже не обдуман. А возможно, стоит. А возможно, и не стоит.