![[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
no subject
no subject
no subject
Не писать мне повестей-романов...
Лучше уж "плюет". Как-то еще образней получается.
Re: Не писать мне повестей-романов...
Re: Не писать мне повестей-романов...
no subject
no subject
no subject
no subject
4 пункт и вот это http://metaclass.livejournal.com/549262.html?thread=7371150#t7371150
Реюз кода в SQL действительно тоже печален, я забыл про его упомянуть.
Первый пункт теоретически разрешим и не требует от СУБД на самом деле особых функций, это вопросы к клиентским тулсам скорее.
VCS и alter table даже теоретически непонятно как решить, это действительно естественное ограничение парадигмы на данный момент.
no subject
Реюз кода это я согласен, но в классической теории СУБД кода нет :)
no subject
no subject
no subject
Вот это меня, кстати, больше всего бесит.
Кзаалось бы, всё чотко и формально. Хуй-то там.
no subject
no subject
Надо посмотреть.
no subject
http://research.nii.ac.jp/~hu/pub/icfp10a.pdf
;)
no subject
no subject
Говорят, что разные версии данных есть, но обратиться нельзя.
no subject
Но на самом деле, если реализовывать версионность самому в базе, то реально сервер версии не хранит и мусор не накапливает, т.е. эта функция СУБД не используется.
no subject
no subject
Пример. Есть запрос, который собирает некоторый объект (граф объектов) из n табалиц. И есть банч условий, скажем, верхнего уровня (к конечному графу), по которому надо фильтровать результат, т.е. 1) получить граф, у которого все теплое, 2) получить граф, у которого все мягкое и т.п. Получается, что запрос отличается только налагаемым условием, но, в моем представлении, нет никакого способа средствами SQL, чтобы скомбинировать код- наследование, аггрегация,- чтобы избежать дублежа, поэтому либо надо шаманить ручками, и собирать запрос на лету, либо держать на 99% идентичные запросы. Может быть, я не в курсе широко известной сильвер буллет?
no subject
no subject
no subject
Тут видимо речь идет о "1+N результатах" :)
no subject
no subject
no subject