###,

Имелось ввиду не существующий, а "усовершенствованный" SQL с ограничениям накладываемыми 2 НФ, то есть в запросе подразумевается разделение на ключи и т.д. На самом деле у него немного другой синтаксис соответственно должен быть, но это косметическое преобразование.

Не цепляйтесь к словам, попробуйте мыслить более глобально...

Пилотажный,

Про нормальную форму я с потолка ляпнул, я имел ввиду наличие ключей и связей только ключей, то есть именно когда таблица - отображение множества на значения. Но согласитесь что в прикладных задачах почти всегда так и есть. А какая это 3 или 5 форма честно гря не помню, но может потом посмотрю...

А то что вы описали и есть рекурсивные CTE, и они вошли в стандарт SQL-1999 и поддерживается почти всеми "приличными" СУБД.

MasterZiv, сложность Brainfuck'а обусловлена принципиально коротким синтаксисом, в аналогичном C++ смотрелось бы проще. Хотя в чем то вы правы.

Подытожу все что я утверждал:
Чтобы не было претензий к нормальным формам, введем понятие ключевой формы - БД удовлетворяет ей если в ней у любой таблицы (запроса) есть ключевые колонки. Соответственно JOIN всегда идет по этим колонкам. То есть любая таблица (запрос) расматривается как отображение ключей (параметров) на значение (что кстати де-факто в математике и является определением функции).

Тезис 1: 99% БД - в ключевой форме. То есть это не я придумал эту форму, это де-факто есть сейчас.
Тезис 2: SQL при использовании с БД в ключевой форме - соотвествует всем принципам функционального программирования - то есть по сути является функциональным языком.
Тезис 3: SQL-1999 в ключевой форме, реализует уже не реляционную, а классическую "функциональную" алгебру (а частности используемую в частично-рекурсивных функциях, ну и вообще в математических функциях)

Изначально у многих здесь складывается впечатление что ФП - это лямбда-исчисление. То есть если бы автор назвал бы тему лямбда-исчисление в программировании, то да SQL был бы ни при чем. А так SQL самый яркий и популярный пример ФП.

Gluk, специально для вас. Не надо спорить про ключевую форму - это определение, которое я ввел в этом посте. Спорить с определениями глупо, под обсуждение попадает тезисы, в частности - Тезис 1.

Gluk (Kazan), издеваешься? SELECT a.value+1 FROM a - изобразил...

Совет, если ты чего-то не понимаешь, то это не значит что не понимают все остальные... Не надо считать себя умнее остальных ;-)

Gluk (Kazan),

Млин, мне все разжевывать? SELECT a.x1,...,a.xn,a.value+1 FROM a... Вообще в SQL есть дебилизм с неоднозначным определением ключей, то есть в идеале (если бы SQL проецировался изначально в ключевой форме) синтаксис должен был быть следующим SELECT {n} a.value+1 JOIN a.x1=keys.1 AND a.x2=keys.2 ... AND a.xn+keys.n, но что выросло то выросло....

Хотя в общем случае конечно функция следования выглядит как SELECT N.key,N.value+1 FROM N, где N - тождественная функция, в рекурсивном CTE - задается как
with N(key,x) {
SELECT N.key+1,N.x+1 FROM N
}
ну или что-то типа того. Но опять-таки в чистом виде функция следования в SQL обычно не используется.

Что такое оператор?

Gluk (Kazan),

Почему, я реализовал выше... Просто SQL сервера ее выполнить не смогут (хотя может есть и те кто смогут). Кроме того функции следования, как и нулевые, в чистом виде на практике не используется. Так что это ты уже теоретизированием занимаешься.

Gluk (Kazan), все завязываем, я вижу что ты совсем невъезжаешь, без обид...

Ggg_old,

Кстати, а лямбда-исчисление вообще говорит что-нибудь о декларативности. То есть я как понимаю оно говорит о возможности создания новых функций из уже существующих, но про базовый класс функций ничего не сказано. Он вообще предполагается императивный или декларативный?