![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Опять RDBMS срач
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
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 - хрен его знает, наверно теорию применения изменений в графах неебического размера придумывать надо, и использовать БД, которая не удаляет данные даже если их дропнули, изменили, итд. Тогда откатится будет в некоторых случаях возможно. Что делать с стогигабайтными БД в таком случае - наверно вешаться.
И в системы контроля версий встраивать модули интеграции с БД, которые бы генерировали скрипты применения и отмены изменений. Или при разработке с использованием БД использовать систему контроля версий прямо в этой же БД, с явной процедурой деплоймента, т.е. созданием из текущей ревизии собранного кода+все миграции со всех других вариантов БД из прошлых ревизий.
no subject
— Доктор, если я делаю так — мне больно.
— Да? Ну тогда так не делайте.
По определению база - это нечто внешнее к программе. С таким же успехом можно причитать, что сайт президента РБ хреново приспособлен к типизированным языкам - постоянно приходится делать что-то вроде FieldByName. OWM и тому подобное - это так, паллиатив, вынесли литералы из кода в конфиги.
2) Хреновое взаимодействие с контролем версий. Я бы сказал, очень хреновое, т.к. в общем случае изменения в базе необратимы, в отличие от кода в VCS.
Во-первых, код или данные? Если данные - то эту тему есть пара книжек. Даже порывались внести нечто подобное в стандарт, да передумали. К слову сказать, та же оракла позволяет с этим делом уже сейчас нормально жить. Не без ограничений, увы.
Если код - то не понимаю, что препятствует держать его во всяких VCS.
П.3 - если не делать себе больно как в п.1, то alter table сказать гораздо проще, чем изменить и перекомпилировать код. Угу-угу.
П.4 - судя по всему, это проблемы файрбёрда. По крайней мере с этим проблем как-то не испытывал.
no subject
Это вообще проблема адо.нет.
Но тем не менее, способ "получить запись и связанные с ней" в серверах бы не помешал. Вместо того чтобы каждый раз это делать в клиентском коде или использовать ORM.
no subject
В оракле он есть из коробки, в постгресе изготавливается вручную за пять секунд (для похапе и прочих сидиезных жаб, для перла он тоже из коробки).
no subject
no subject
no subject
И кто их потом закроет, когда я фетч завершу?
no subject
Да, конечно
И кто их потом закроет, когда я фетч завершу?
Закроются сами при завершении транзакции.
no subject
Или вложенные курсоры можно принудительно закрыть?
no subject
Курсор создается как табличка в памяти. Хватит памяти - не умрет. Хотя я не очень понимаю, зачем такое может потребоваться. Несколько тысяч курсоров - вполне нормально, но мне и такое не требовалось.
Или вложенные курсоры можно принудительно закрыть?
Это обычные курсоры, ради бога.
no subject
К примеру с сайтом - очевидно лучше вместо ориентированного на просмотр пользователем html иметь возможность читать непосредственно данные.
no subject
Вы что-то как О.Бендер, который видел основную причину скверных снов Хворобьева в советской власти. "База как нечто внешнее по отношению к программе" - это не причина, это данность, если только не мыслить в стиле айн фольк - айн фюрер, айн аппликейшн - айн база.
no subject