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

WH>На практике нам нужно нарушать оба условия.
WH>Таким образом, язык работы с БД не может быть построен на отношениях.
WH>Что на практике и происходит. Например, order by или top для отношений просто не имеют смысла.
А, это-то фигня. Это тривиальное расширение понятия relation, и я про него в курсе. Просто в рамках этого топика не хотел переусложнять на ровном месте.

WH>По всей видимости, наиболее адекватной моделью будут списки кортежей с именованными полями.
Не, не списки. Список задаёт ad-hoc порядок, а нам интересен ключ упорядочивания и ещё кое-какие метаданные.

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

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

Осталось приделать к этому приемлемый синтаксис, и золотой ключик у нас в кармане.