Опять RDBMS срач

[metaclass]

zabivator опять поднял свою любимую тему.

Я таки сформулировал, чего меня не устраивает в РСУБД, перепощу сюда чтобы не забыть:

Что меня бесит в СУБД:

1) Хреновая интеграция баз и статически типизированных языков. Т.е. постоянно нужно делать что-то вроде FieldByName("имя_поля") и тому подобное, что очень легко сломать. Обходится кодогенерацией из схемы базы или из запросов и проверкой при запуске что схему не изменили несовместимым образом. ORM и тому подобное - это так, паллиатив, вынесли литералы из кода в конфиги.

2) Хреновое взаимодействие с контролем версий. Я бы сказал, очень хреновое, т.к. в общем случае изменения в базе необратимы, в отличие от кода в VCS. Как решить - а хер его знает, т.к. в отличие от кода, который можно откатить на старую версию по частям и в худшем случае он просто не соберется, в базе все взаимосвязано так, что хрен ты откатишь одно изменение, если поверх него уже сделаны другие. Я даже теоретически себе это с трудом представляю. Короче "самосогласованный откат изменений в графе", можно вешаться.

3) Это тоже относится к 2) про это еще rainman_rocks писал - программисты ненавидят ALTER TABLE, т.к. изменить и перекомпилировать код гораздо проще чем изменить базу.

4) Хреновейшая работа с вложенными коллекциями и вообще всем, что сложнее чем "список плоских записей". Проблема 1+N запросов и тому подобное. Лечится исключительно методом "встраиваем прямо внутрь БД сборку сложных объектов из результатов запросов и сериализацию полученного в какой-нибудь JSON", поимев в результате логику в БД, зависимости от таблиц и прочий шлак. Еще можно рядом с СУБД поставить сервер приложений, делающий то же самое, но внутри сервера быстрее. А еще в дотнете в норме 1+N запрос еще и не выполнишь - не у всех драйверов доступа можно лениво фетчить одновременно из двух резальтсетов.


1 и 4 можно исправить, впилив в сервер какой-нибудь язык с явной поддержкой нормальных типов(кто сказал Haskell?), а в клиентскую либу вставив автоматическую кодогенерацию (на всех over 9000 языках) из запросов и проверку схемы при подключении.

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

Comments

[thesz.livejournal.com]

Bidirectionalizing Graph Transformations Soichiro Hidaka (National Institute of Informatics, Japan); Zhenjiang Hu (National Institute of Informatics, Japan); Kazuhiro Inaba (National Institute of Informatics, Japan); Hiroyuki Kato (National Institute of Informatics, Japan); Kazutaka Matsuda (Tohoku University, Japan); Keisuke Nakano (University of Electro-Communications, Japan)

http://research.nii.ac.jp/~hu/pub/icfp10a.pdf

;)

[kurilka.livejournal.com]

не нашёл там ни одного упоминания postgres, это где-то между строк написано?

[thesz.livejournal.com]

http://bytes.com/topic/postgresql/answers/173974-versioning-control-postgresql

Говорят, что разные версии данных есть, но обратиться нельзя.

[metaclass.livejournal.com]

А, MVCC архитектура СУБД - меня мысль насчет того, что база умеет внутри себя хранить версии, а я потом поверх этого еще раз делаю версионность, печалит. В Firebird то же самое.

Но на самом деле, если реализовывать версионность самому в базе, то реально сервер версии не хранит и мусор не накапливает, т.е. эта функция СУБД не используется.

[nivanych.livejournal.com]

Спасибо, довольно любопытная статья.