Ещё раз про базы данных

[dair_targ_one]

В продолжение прошлого поста.

1. Каждый экземпляр приложения при работе с БД открывает сессию, в которой должны быть указаны название и версия приложения, а так же уникальный идентификатор этого приложения.
2. Типы записей. Хорошо бы иметь алгебраические типы, функциональные и возможность ссылаться на другие записи в БД -- это какое-нибудь обобщение

Comments

[ex_juan_gan]

Горячо поддерживаю.
По 8 пункту - по большей части не нужны, но, по-моему, технически базы устроены так, что при вставке лучше транзакцию иметь.

[dair_targ_one]

Транзакцию нужно иметь, если операции не атомарные. А вот вставка значения в дерево и в множество -- атомарные. Так что вроде как можно и без них.

Мне тут самая интересная часть -- вопросы из п.2. Это скорее куда-то в математику, с которой у меня не очень хорошо. Если можете подсказать ключевые слова или статьи какие -- буду очень благодарен.

[ex_juan_gan]

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

[cross_join]

Предыдущая попытка обсудить концепцию идеальной БД у нас на форуме закончилась неудачно :)
http://www.arbinada.com/main/node/1265

[larzul]

Вопрос далекого от дбдизайна человека: в каких ситуациях описанный подход лучше обычного журналирования транзакций, которое есть вроде как везде? Частое обращение к прошлым значениям?

[metaclass]

Полный аудит действий с базой. Его почти всегда приходится и так делать.
Репликация и прочее требующее истории (например, перерасчеты каких-нибудь заумных агрегатов по требованию) практически на халяву.
Более аккуратная нагрузка на i/o при записи - "только дописываем в конец". При этом, впрочем с индексами ситуация не совсем понятная, их можно сделать тоже из иммутабельных структур, но не совсем понятно, насколько это хорошо.
Инкрементальные бэкапы методом "сохранили кусок файла от предыдущей позиции до конца".

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

[dair_targ_one]

Подозреваю, что "интегральное состояние" в такой БД можно и нужно делать на уровне движка. В конце концов никто не запрещает записывать однажды посчитанные значения.

[metaclass]

Да, мемоизировать результаты запросов можно.

Вот инвалидация и пересчет этих результатов - негуманный процесс. Т.к. надо пройтись по логу от версии, на которой результат был посчитан до текущей видимой зафиксированной транзакции и проверить "влияет ли изменение на результат".

[akuklev]

Datomic?

[dair_targ_one]

С виду оно. Жаль, что не SQL-like и жаль, что для non-jvm языков только http api.
Благодарю за ссылку!

[akuklev]

Оно datalog поддерживает, а datalog это удивительная сила. По-существу это рекурсивный SQL, хотя синтаксис у него не такой ортогональный.

См. http://stackoverflow.com/questions/2117651/difference-between-sql-and-prolog
http://infolab.stanford.edu/~ullman/fcdb/aut07/slides/dlog.pdf

Вообще датомик весьма крут идейно, но его закрытость и некоторые аспекты реализации очень бесят.