Уныние RDBMS

[metaclass]

Лента заполнена анонсами PostgreSQL 9.0. Читаю release notes, куча всего полезного, только вот в последнее время я перестал понимать, зачем на уровне базы данных это все делать, если вдруг понадобится проект запустить на другой СУБД.
Долбаные разные диалекты SQL задолбали даже в плане запросов, а уж про триггера и хранимые процедуры и речи не идет
В общем, либо страдать пакостью вроде "используем общее множество функций, а все недостающее делаем, как дебилы руками в слое доступа к БД", т.е. фактически "перепишем 2/3 СУБД вручную на дотнете криво и убого", либо на веки вечные привязываемся к одной СУБД и используем ее на полную катушку.

Comments

[ok-its-the-last.livejournal.com]

А что, кто-то реально меняет базы?

[chepikoff.livejournal.com]

Бывает еще, что серверов баз данных сильно больше одного.

[inv2004.livejournal.com]

Смена базы бывает только в одном варианте: база X -> oracle. поэтому согласен, писать что-то на внутренностях postgresql - странно.

[kisa-i-osya.livejournal.com]

Если говорить о PostgreSQL, то, кстати, я ни разу его за "основную" базу не видел, всегда рядом что-то еще крутилось.

[permea-kra.livejournal.com]

Есть ещё вариант 'Пишем кодогенератов из кошерного диалекта SQL в диалекты баз'. Хотите попробовать?

[ennor.livejournal.com]

Не вижу ничего плохого в третьем варианте - разумеется, если это не опенсорс СУБД, которая сегодня развивается, а завтра ее сайт исчез и до свиданья.

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

Не, я знаю, что можно аксапту на оракле поднять, а сап наоборот на mssql, но я не знаю, кем надо быть, чтобы втравить свою контору в подобную авантюру...

[nivanych.livejournal.com]

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

[alextutubalin.livejournal.com]

либо на веки вечные привязываемся к одной СУБД и используем ее на полную катушку.

Раз уж я сюда пришел....

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

Другой вопрос, что эффективность кода практически никогда не парит, все упирается в более медленные устройства.

Вот с СУБД оно проявлено просто острее. Ну несовершенны оптимизаторы и максимально эффективные запросы для разных СУБД будут разными (пусть даже оба исполняются). И вот с этим и жить. А если запросы разные, то значит весь db layer меняется и дальше на совместимость уже практически плевать, нету ее.

[zakharchemodan.livejournal.com]

Извиняюсь, есть предложение пойти по другому пути.