Отнесение SQL к какому либо уровню достаточно сложно, так как SQL не проектировался, как полноценный язык программирования. Это DSL для работы с данными.
В языке запросов SQL можно увидеть неполное освоение уровня иерархий и правил. Декомпозиция на под-запросы поддержана очень плохо. Переиспользуемые (в том числе и в других запросах) параметризованные запросы до сих пор плохо стандартизованы, а где есть, требуют некоторых специальных усилий. Также SQL очень плохо обрабатывает иерархические структуры данных, даже с последними расширениями. В этом отношении интересен Datalog, который является языком уровня иерархий и правил с самого начала, хотя и с существенными ограничениями.
На уровне определения данных, схожие проблемы. SQL базы данных плохо поддерживают рекурсивные структуры. Эти структуры определяются через отношения, и их создание обработка выглядят несколько противоестественными. И даже определяемые пользователем типы данных, еще не везде внедрены, и они ограничиваются только набором полей. Нельзя сделать из такой структуры ссылку на таблицу (не в одной базе, которую я смотрел, нельзя даже определить foreign key из структуры).
То есть, на текущем уровне SQL это скорее 2+, уровень сочетаний и рецептов с некоторыми фичами следующих уровней, но которые не встроены полноценно в язык. Это как указатели на функции в С. Вроде есть, но пользоваться очень сложно и нужны многочисленные дополнительные приседания.
Я думаю, что эти проблемы вызваны отношением к SQL как к DSL. Если мы хотим расширить круг пользователей, DSL должен быть где-то на уровень ниже основного языка, что бы упростить использование.
Проблемы с SQL хорошо видны на кривой возрастания сложности. SQL запрос на 90 строчек - это просто ужас-ужас-ужас. Тогда как для C программы это нормально, а на Java очень редкие программы меньше. Это все связанно с использованием инструментов сознания для организации кода, чем ниже уровень инструмента, тем меньше кода он может организовать с приемлемой сложностью.
В OODB попытались сделать уровень 4 (модели), но там возникли другие проблемы, связанные выбранной технологией интеграции с языками программирования. Так же уровень мета-правил (FP) не поддерживался в тех реализациях, с которыми я знаком.
ИМХО задачу обработки и хранения данных уже пора решать с помощью полноценного и полного языка программирования, а не в виде DSL. Некоторые NoSQL базы в этом направлении движутся, но как-то очень робко.
Вот тут я не согласен. По-моему, SQL как раз очень хорошо и мощно поддерживает работу с данными, включая описание структуры и сложное манипулирование ими. Просто это совершенно другая парадигма устройства мира, нежели обычный процедурный подход. И мир, который там описывается - довольно сложный. Поэтому для восприятия сложных конструкций, требуется "вывернуть мозги", преодолеть сложность этого подхода, а без этого не получается. воспринимаешь это как "ужас-ужас". С моей точки зрения, это - свидетельство высокого уровня сложности языка, а не низкого.
А как раз возможность воспринимать длинные линейные конструкции - наоборот, свидетельство низкой сложности языка, ты пишешь на нем простые линейные тексты, которые хорошо читаются, и что?
Что касается ООDB, то там как раз никаких уровней сложности нет, это просто хранилка к ОО-структурам данных - сложность которых не слишком велика. иерархия и все. А вот настоящий синтез возникает в C# с linq - который инкорпорировал сложность и многообразие SQL в смысле организации данных в не менее сложный OO-язык.
В языке запросов SQL можно увидеть неполное освоение уровня иерархий и правил. Декомпозиция на под-запросы поддержана очень плохо. Переиспользуемые (в том числе и в других запросах) параметризованные запросы до сих пор плохо стандартизованы, а где есть, требуют некоторых специальных усилий. Также SQL очень плохо обрабатывает иерархические структуры данных, даже с последними расширениями. В этом отношении интересен Datalog, который является языком уровня иерархий и правил с самого начала, хотя и с существенными ограничениями.
На уровне определения данных, схожие проблемы. SQL базы данных плохо поддерживают рекурсивные структуры. Эти структуры определяются через отношения, и их создание обработка выглядят несколько противоестественными. И даже определяемые пользователем типы данных, еще не везде внедрены, и они ограничиваются только набором полей. Нельзя сделать из такой структуры ссылку на таблицу (не в одной базе, которую я смотрел, нельзя даже определить foreign key из структуры).
То есть, на текущем уровне SQL это скорее 2+, уровень сочетаний и рецептов с некоторыми фичами следующих уровней, но которые не встроены полноценно в язык. Это как указатели на функции в С. Вроде есть, но пользоваться очень сложно и нужны многочисленные дополнительные приседания.
Я думаю, что эти проблемы вызваны отношением к SQL как к DSL. Если мы хотим расширить круг пользователей, DSL должен быть где-то на уровень ниже основного языка, что бы упростить использование.
Проблемы с SQL хорошо видны на кривой возрастания сложности. SQL запрос на 90 строчек - это просто ужас-ужас-ужас. Тогда как для C программы это нормально, а на Java очень редкие программы меньше. Это все связанно с использованием инструментов сознания для организации кода, чем ниже уровень инструмента, тем меньше кода он может организовать с приемлемой сложностью.
В OODB попытались сделать уровень 4 (модели), но там возникли другие проблемы, связанные выбранной технологией интеграции с языками программирования. Так же уровень мета-правил (FP) не поддерживался в тех реализациях, с которыми я знаком.
ИМХО задачу обработки и хранения данных уже пора решать с помощью полноценного и полного языка программирования, а не в виде DSL. Некоторые NoSQL базы в этом направлении движутся, но как-то очень робко.
Reply
А как раз возможность воспринимать длинные линейные конструкции - наоборот, свидетельство низкой сложности языка, ты пишешь на нем простые линейные тексты, которые хорошо читаются, и что?
Что касается ООDB, то там как раз никаких уровней сложности нет, это просто хранилка к ОО-структурам данных - сложность которых не слишком велика. иерархия и все. А вот настоящий синтез возникает в C# с linq - который инкорпорировал сложность и многообразие SQL в смысле организации данных в не менее сложный OO-язык.
Reply
Reply
Leave a comment