Почему SQL известен как основанный на отношениях / функциональный язык?

Мы узнаем, что большинство языков классифицируются как «отношения на основе» или «высокий уровень». Я никогда раньше не использовал SQL, но, читая его синтаксис, он больше напоминает синтаксис императив / высокоуровневый, чем функциональный / основанный на отношениях (Lisp, Haskell) ??

Или, может быть, моя интерпретация лекций моего профессора неверна ... но в нем определенно указан SQL как один из языков, основанных на отношениях (в отличие от высокого уровня), и он приравнивает основанный на отношениях к функционалу ... или, может быть, я не понимаю, почему тот факт, что SQL работает с реляционными базами данных, делает функциональный язык таким, каким он должен быть реализован? (и почему «основанный на отношениях» приравнивается к «функциональному» при категоризации языков программирования?)

Благодарность :)

Мы узнаем, что большинство языков классифицируются как «отношения на основе» или «высокий уровень».

Эти понятия ортогональны. «На основе отношений» означает, что семантика языка основана на концепции отношения, то есть связи многих ко многим между двумя наборами (отношения являются математической основой таблиц SQL). «Высокий уровень» означает, что язык содержит множество абстракций, которые скрывают большую часть технических деталей (таких как области памяти, регистры ЦП, доступ к диску, побитовые операции и т. Д.). SQL, безусловно, основан на отношениях, поскольку его основная цель - описать реляционные данные и операции над ними. SQL также довольно высокого уровня; он не предоставляет никаких средств для непосредственного доступа к байту на диске и не сообщает никаких подробностей о том, как он хранит свои данные (по крайней мере, стандартный SQL этого не делает;

На самом деле существует гораздо больше осей, по которым можно классифицировать языки программирования (и данных); особенно интересным является декларативный против императив . Декларативные языки описывают то , что что - то есть ; императивные языки описывают, как сделать что-то. DDL часть SQL в основном декларативный, несмотря на настоятельные перспективных ключевых слов (» CREATE TABLE», „ DROP DATABASE“ и т.д.), и даже манипулирования данными часть ( SELECT, UPDATE, INSERT, DELETE) все еще довольно декларативным. Очень интересное свойство SQL состоит в том, что он не является полным по Тьюрингу: вы не можете написать неограниченный цикл в простом стандартном ANSI SQL.

Функциональное программирование сосредоточено вокруг нескольких основных идей:

• функции являются гражданами первого класса (то есть их можно использовать как значения, как входные данные для других функций и как выходные данные для других функций)
• функции высшего порядка (функции, которые работают с функциями, или функции, которые возвращают функции)
• чистота (чистая функция - это та, которая не имеет побочных эффектов; чистая функция не может выполнять какие-либо операции ввода-вывода, она не может читать или изменять любое глобальное состояние и не может принимать неконстантные ссылочные аргументы. Чистые функции особенно интересны, потому что они будут всегда выдают одинаковый результат при одинаковых входах)

SQL, конечно, не вращается вокруг функций как основного инструмента для моделирования вещей, но он в некоторой степени охватывает идею чистоты - один и тот же запрос, выполняемый в одной и той же базе данных, каждый раз будет давать один и тот же результат (кроме порядка). Называть SQL «функциональным» языком немного сложнее, хотя IMO.

SQL не является обязательным, потому что процесс HOW-запросов и отношений разрешается не программистом, а компилятором / оптимизатором / интерпретатором. SQL - это декларативный язык. В SQL вы объявляете отношения. Это создает структуру данных (которая опять-таки определяется не физически языком, а его реализацией) с использованием вставок, обновлений и удалений.

Затем использование отношений выполняется с использованием запросов (операторов SELECT), которые функциональны в том смысле, что не имеют побочных эффектов.

Все это обернуто вокруг реляционной модели .

SQL на самом деле не столько функциональный язык, сколько декларативный. Функциональные языки, в общем, подчеркивают декларативный стиль, а не императив, чтобы минимизировать побочные эффекты. Это может побудить некоторых людей ссылаться на SQL как на функциональный, но он не точен. Это декларативно с процедурными элементами.

Возможно ли, что ваши записи зашифрованы?

Я никогда не слышал о том, чтобы языки программирования были разделены на «отношения на основе» и «высокий уровень». Низкий уровень / Высокий уровень обычно используется, чтобы отличить ассемблер и C от языков, которые обеспечивают непосредственную поддержку более абстрактных структур. Отношения - это довольно абстрактная структура, поэтому я бы сказал, что все, что поддерживает отношения, является высокоуровневым по определению.

Чистый SQL обычно описывают как декларативный язык, с некоторыми процедурными частями, взятыми различными поставщиками. Мне кажется, тот факт, что SQL не поддерживает функции как переменные, немедленно лишает его функциональности.

SQL - это реляционный язык, основанный на множествах, с функциональной функциональностью.

Я не знаю, считаю ли я SQL функциональным, однако в нем есть некоторые аспекты функциональных языков. Современные варианты SQL (с процедурными битами) определенно не работают.

Я думаю, что SQL - это синтаксический сахар вокруг реляционной алгебры + нечто большее. Реляционная алгебра обладает большой силой функциональных языков, она действительно использует функции с очень высокой степенью выраженности (выбор, проекция, переименование, объединение, объединение, пересечение ...). Но, насколько мне известно, базовый подход к реляционной алгебре обычно не имеет эквивалента лямбда-оператора, хотя он может быть беспрепятственно расширен с помощью оператора рекурсии.

Я думаю, что алгебра отношений - это скорее алгебраический язык. SQL с его подзапросами перешел от чисто реляционной алгебры к более функциональному стилю, но без лямбда-оператора, я думаю, это не полнофункциональный язык. Я не знаю, может ли это быть расширено до полнофункционального языка без проблем, я не эксперт в этой области. У Haskell есть несколько библиотек с целью использования языков баз данных очень высокого уровня.

Я не знаю всех тонкостей того, что нужно для того, чтобы язык был квалифицирован как функциональный, но в Sql Server появился очень интересный способ работы с функциями. Специальное предложение позволяет функциям взаимодействовать друг с другом в запросе. Это называется Применить. Когда я объяснил это бывшему программисту APL, он сказал мне, что подобное предложение существует в APL для аналогичной цели. Предложение Apply позволяет передавать набор атрибутов из строки таблицы или строки табличной функции в качестве входных данных для другой функции. При этом я наложил ограничение на тип табличной функции для записи, чтобы она считалась функциональной. Должен быть объявлен как встроенный, что означает, что он выражается как один оператор выбора. Это навязывает отсутствие переменных. Такие запросы с большим количеством логики могут быть написаны при условии, что вы используете общие табличные выражения, которые затем позволяют превращать выражения в столбцы, разновидность неизменяемой переменной, которую можно использовать в другом CTE. В конце концов, функция .f становится очень большим макросом, который освобождает оптимизатор для оптимизации так, как ему нужно. Единственное, чего не хватает людям, - это несколько простых приемов для написания условной логики и объявления некоторых данных, поддерживающих логику в запросе. Наконец, некоторые функции, использующие предложение over, необходимы для передачи результатов в виде значения, используемого в строке из других строк, но здесь было бы немного доработать. Единственное, чего не хватает людям, - это несколько простых приемов написания условной логики и декларирования некоторых данных, поддерживающих логику в запросе. Наконец, некоторые функции, использующие предложение over, необходимы для передачи результатов в виде значения, используемого в строке из других строк, но здесь было бы немного доработать. Единственное, чего не хватает людям, - это несколько простых приемов написания условной логики и декларирования некоторых данных, поддерживающих логику в запросе. Наконец, некоторые функции, использующие предложение over, необходимы для передачи результатов в виде значения, используемого в строке из других строк, но здесь было бы немного доработать.