Уныние RDBMS
Sep. 20th, 2010 01:34 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassЛента заполнена анонсами PostgreSQL 9.0. Читаю release notes, куча всего полезного, только вот в последнее время я перестал понимать, зачем на уровне базы данных это все делать, если вдруг понадобится проект запустить на другой СУБД.
Долбаные разные диалекты SQL задолбали даже в плане запросов, а уж про триггера и хранимые процедуры и речи не идет
В общем, либо страдать пакостью вроде "используем общее множество функций, а все недостающее делаем, как дебилы руками в слое доступа к БД", т.е. фактически "перепишем 2/3 СУБД вручную на дотнете криво и убого", либо на веки вечные привязываемся к одной СУБД и используем ее на полную катушку.
Долбаные разные диалекты SQL задолбали даже в плане запросов, а уж про триггера и хранимые процедуры и речи не идет
В общем, либо страдать пакостью вроде "используем общее множество функций, а все недостающее делаем, как дебилы руками в слое доступа к БД", т.е. фактически "перепишем 2/3 СУБД вручную на дотнете криво и убого", либо на веки вечные привязываемся к одной СУБД и используем ее на полную катушку.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-09-21 09:22 am (UTC)Раз уж я сюда пришел....
Понимаете, с процессорами оно совершенно аналогично - если хочется писать эффективный код, то его надо оптимизировать под процессор. И даже два почти одинаковых но с разным размером кэша - код будет разный (точнее, всякие константы в коде, отвечающие за working set)
Другой вопрос, что эффективность кода практически никогда не парит, все упирается в более медленные устройства.
Вот с СУБД оно проявлено просто острее. Ну несовершенны оптимизаторы и максимально эффективные запросы для разных СУБД будут разными (пусть даже оба исполняются). И вот с этим и жить. А если запросы разные, то значит весь db layer меняется и дальше на совместимость уже практически плевать, нету ее.