Здравствуйте, Sinclair, Вы писали:

S>А, ну так состав операций никак не изменился.
Да я бы не сказал.

S>Вообще, все нужные операции уже давно описаны Коддом.
S>Проблема SQL — только в том, что в нём нет понятия "функция" в широком смысле. И тем более нет понятия "функция высшего порядка".
На самом деле все гораздо хуже.

A relation is a data structure which consists of a heading and an unordered set of tuples which share the same type.

Те отношение не имеет порядка.
В отношении не может быть дублей.
На практике нам нужно нарушать оба условия.
Таким образом, язык работы с БД не может быть построен на отношениях.
Что на практике и происходит. Например, order by или top для отношений просто не имеют смысла.

По всей видимости, наиболее адекватной моделью будут списки кортежей с именованными полями.
Ибо они с одной стороны поддерживают нужные на практике фичи. И с другой стороны для них можно один в один определить аналоги реляционных операций.
Также с ними будут работать все наработки в области реляционных БД просто по тому, что по факту они и работают со списками кортежей, а не с отношениями.

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