Леланд Ричардсон , основатель Tech.Pro , недавно опубликовал очень интересную статью о BQL, его видении лучшего языка запросов (чем SQL) . Решающим подвигом его нового языкового предложения является тот факт, что это действительно расширенный набор самого SQL.
SQL — очень богатый и выразительный язык для запросов к реляционным базам данных. Но это неловко во многих аспектах, и многие люди чувствуют, что оно развивается медленно, даже если это не так, учитывая темп стандартов SQL. Но стандарт — это одно, реализации — другое, особенно на предприятии. Когда мы ведем блог о SQL, мы постоянно удивляемся , насколько удивительным является диалект PostgreSQL . Но часто PostgreSQL просто реализует стандарт. Так что есть надежда, что мы куда-то доберемся.
Тем не менее, в статье Леланда есть пара идей, которые стоит рассмотреть. С нашей точки зрения, это в основном:
Гибкость при заказе предложения SELECT и табличного выражения
В SQL SELECT всегда является первым ключевым словом. Это должно быть выражено перед табличным выражением. В предыдущей статье мы показали, что это вводит в заблуждение многих пользователей SQL . Хотя существующий синтаксис должен продолжать существовать, было бы хорошо иметь возможность инвертировать предложение SELECT и табличное выражение.
|
1
2
3
4
|
FROM tableWHERE predicateGROUP BY columnsSELECT columns |
Помните, что табличное выражение содержит предложения FROM , WHERE , GROUP BY , а также предложения CONNECT BY относящиеся к конкретному поставщику, и другие:
|
1
2
3
|
<query specification> ::= SELECT [ <set quantifier> ] <select list> <table expression> |
Кстати, эта языковая функция уже доступна в LINQ .
Неявные ключевые соединения
Эта функция также доступна в jOOQ , используя предложение ON KEY . Обратите внимание, что Sybase также поддерживает соединения ON KEY :
|
1
2
3
4
|
from post key join userkey join commentselect * |
Названные прогнозы
Это одна из особенностей, которую мы действительно хотим, чтобы язык SQL имел. Однако мы не будем рассчитывать на указание проекций в выделенном синтаксисе. Мы скорее использовали расширение синтаксиса табличных выражений, позволяющее таблице создавать «боковые таблицы» как таковые:
|
1
2
3
4
5
|
from dbo.userswith projection as ( firstName, lastName, phoneNumber, email)select projection.* |
В приведенном выше примере projection — это не что иное, как другое табличное выражение, полученное из таблицы users . Исходя из семантики синтаксиса SQL, это было бы чрезвычайно эффективно, поскольку такие проекции наследовали бы все синтаксические особенности обычной таблицы. Мы уже писали об этом раньше, когда называли эту функцию «выражениями общего столбца» .
Вывод
У Леланда есть много других идей. Он только в начале проекта, который все еще нуждается в доработке. Однако отзывы о Reddit довольно хорошие . Ясно, что существует большой потенциал в создании «BQL» для SQL, что
Давайте посмотрим, куда ведет это усилие. Мы обязательно будем следить за дальнейшими шагами BQL.
| Ссылка: | Язык запросов лучше, чем SQL, от нашего партнера по JCG Лукаса Эдера из блога JAVA, SQL и JOOQ . |