Я считаю, что при использовании SQL мы совершаем фундаментальную ошибку. Мы используем его как для того, чтобы задать вопрос, так и для форматирования ответа.
Позвольте мне привести пример генерации XML с помощью SQL:
(Тот же аргумент можно использовать с использованием JSON или любого другого языка разметки. Я использую XML только в качестве примера.)
Вот один из бесчисленных способов генерации XML с помощью SQL в базе данных Oracle:
ВЫБРАТЬ XMLELEMENT («Emp», XMLATTRIBUTES (e.fname AS «firstName»))
ОТ сотрудников e
Ниже приведен пример фрагмента XML, который этот оператор SQL может создать при выполнении:
‹Emp firstName =" John "/›
‹Emp firstName =" Mary "/›
Так же,
ВЫБРАТЬ XMLELEMENT («Emp», XMLELEMENT («firstName», e.fname))
ОТ сотрудников e
возвращает следующий фрагмент XML:
‹Emp›
‹firstName› Джон ‹/firstName›
‹/Emp›
‹Emp›
‹firstName› Мэри ‹/firstName›
‹ / Emp ›
По логике, два оператора задают один и тот же вопрос базе данных (выберите fname из сотрудников) и должны возвращать один и тот же ответ, если данные статичны. Отличается только формат ответа. Однако два оператора SQL выглядят по-разному, потому что способ представления данных скрыт внутри оператора SQL. Другими словами, SQL используется не только для того, чтобы задать вопрос, но и для форматирования ответа на вопрос.
У этого подхода есть несколько недостатков. Это затрудняет написание и понимание операторов SQL. Это затрудняет их обслуживание, особенно если изменения в формате значительны. Что еще хуже, каждый другой формат требует написания нового оператора SQL, даже если мы можем задать тот же самый вопрос, только чтобы получить его в другом формате.
Альтернативный подход
Я полностью за то, чтобы указать формат ответа, задавая вопрос с помощью SQL. Я согласен с тем, что преобразование ответа в желаемый формат должно быть максимально приближено к кремниевому. Однако, если мы собираемся это сделать, давайте сделаем это правильно и отделим запрос данных от форматирования, которое нам нужно для ответа.
Ниже приведены примеры утверждений, которые возвращают ту же информацию, что и выше. Однако эти заявления состоят из двух частей. Первая часть - это SQL, который задает вопрос, а вторая часть описывает формат, в котором пользователь хочет получить ответ.
Обратите внимание, что я придумал синтаксис. На данный момент меня не волнует конкретный синтаксис для достижения этого разделения. Все, что я пытаюсь показать, это то, что это разделение возможно и очень, очень полезно.
выберите fname
из сотрудников
вернуть XMLType,
строки как xmlTag «Emp»,
столбцы как атрибуты,
переименуйте столбец fname в «firstName ”
приведет к:
‹Emp firstName =" John "/›
‹Emp firstName =" Mary "/›
Так же,
выберите fname
среди сотрудников
вернуть XMLType,
строки как xmlTag «Emp»,
столбцы как теги,
переименуйте столбец fname в «firstName» ”
произвел бы
‹Emp›
‹firstName› Джон ‹/firstName›
‹/Emp›
‹Emp›
‹firstName› Мэри ‹/firstName›
‹ / Emp ›
Используя реализацию синтаксиса, подобную описанной выше, пользователь базы данных может получать данные в любом желаемом формате, будь то XML или JSON. Более того, если синтаксис и его реализация мощные, пользователь может даже описать любой произвольный формат ответа. Эти выходные форматы также можно сохранять и использовать повторно.
Поскольку запрос отделен от представления, оператор SQL становится намного проще писать и более читабельным. Если формат изменится, запрос не изменится. Добавление нового формата представления становится независимым от SQL, необходимого для извлечения данных. Наконец, с достаточно мощной реализацией языка форматирования разработчики могут добавить новый формат представления к оператору SQL во время выполнения в качестве входного параметра:
выберите fname
среди сотрудников
вернуть с помощью myFormat
Как я уже сказал, я не сосредотачиваюсь на собственном синтаксисе языка форматирования. Но давайте не ошибаться. Это новый язык. Итак, я предполагаю, что я говорю, что SQL нужна сестра для форматирования его вывода. Помимо SQL, языка структурированных запросов, нам нужен язык структурированного форматирования и новые механизмы баз данных, которые могут интерпретировать и то, и другое.
Большое спасибо Х. Ибрагиму Сандалли, Сердару Гекчену и Лукасу Эдеру за чтение первых черновиков этой статьи.
