metaclass | Опять RDBMS срач

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

Threaded | Flat

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

— Доктор, если я делаю так — мне больно.
— Да? Ну тогда так не делайте.

По определению база - это нечто внешнее к программе. С таким же успехом можно причитать, что сайт президента РБ хреново приспособлен к типизированным языкам - постоянно приходится делать что-то вроде FieldByName. OWM и тому подобное - это так, паллиатив, вынесли литералы из кода в конфиги.

2) Хреновое взаимодействие с контролем версий. Я бы сказал, очень хреновое, т.к. в общем случае изменения в базе необратимы, в отличие от кода в VCS.

Во-первых, код или данные? Если данные - то эту тему есть пара книжек. Даже порывались внести нечто подобное в стандарт, да передумали. К слову сказать, та же оракла позволяет с этим делом уже сейчас нормально жить. Не без ограничений, увы.
Если код - то не понимаю, что препятствует держать его во всяких VCS.

П.3 - если не делать себе больно как в п.1, то alter table сказать гораздо проще, чем изменить и перекомпилировать код. Угу-угу.

П.4 - судя по всему, это проблемы файрбёрда. По крайней мере с этим проблем как-то не испытывал.

Поправь пост, что ли.

У господина Крокодила мозги серьёзно свернуты в плане работы с базами, так что все грабли РСУБД он обходит машинально и привычно, а на необходимые грабли закрывает глаза. Если взглянуть объективно, то абсолютно все описанные грабли есть объективно существующая действительность.

> Хреновое взаимодействие с контролем версий.

Вот это меня, кстати, больше всего бесит.
Кзаалось бы, всё чотко и формально. Хуй-то там.

А я, ребе, еще писал про плохой код-реюз в SQL, но вы не поддержали- может быть, я неверно выразился.
Пример. Есть запрос, который собирает некоторый объект (граф объектов) из n табалиц. И есть банч условий, скажем, верхнего уровня (к конечному графу), по которому надо фильтровать результат, т.е. 1) получить граф, у которого все теплое, 2) получить граф, у которого все мягкое и т.п. Получается, что запрос отличается только налагаемым условием, но, в моем представлении, нет никакого способа средствами SQL, чтобы скомбинировать код- наследование, аггрегация,- чтобы избежать дублежа, поэтому либо надо шаманить ручками, и собирать запрос на лету, либо держать на 99% идентичные запросы. Может быть, я не в курсе широко известной сильвер буллет?

Проблема 1+N запросов
Тут видимо речь идет о "1+N результатах" :)

no subject

no subject

no subject

no subject

no subject

no subject