Уныние 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-20 01:51 pm (UTC)no subject
Date: 2010-09-20 01:57 pm (UTC)no subject
Date: 2010-09-20 02:01 pm (UTC)no subject
Date: 2010-09-20 02:26 pm (UTC)no subject
Date: 2010-09-20 02:35 pm (UTC)no subject
Date: 2010-09-20 05:12 pm (UTC)С учетом полузаказной разарботки -надо быть готовым выполнить любой каприз заказчика не вспугнув его стоимостью портирования ;)
До фика ))
Date: 2010-09-20 05:19 pm (UTC)no subject
Date: 2010-09-20 08:19 pm (UTC)no subject
Date: 2010-09-21 03:51 am (UTC)no subject
Date: 2010-09-21 06:32 am (UTC)как же оно на постгресе-то вот рядышком стоит? чего я не знаю?
no subject
Date: 2010-09-21 06:35 am (UTC);-) А вот про вас-то и забыли!
> как же оно на постгресе-то вот рядышком стоит?
> чего я не знаю?
Вы что-то делаете не так! ;-)
А если серьёзно, то я сам не пробовал, слышал от товарищей.
Так что, таки под постгресом друпал нормально работает искаропки?
И не надо ничего допиливать?
no subject
Date: 2010-09-21 06:41 am (UTC)специально ничего не пилил.
может ты перепутал? из последнего movable type постгрес вынесли.
no subject
Date: 2010-09-21 06:45 am (UTC)Я ссылаюсь на слова товарищей, которые сейчас пользуют друпал и MySQL.
Если мне с ними придётся работать, то придётся и с MySQL связываться, который я не люблю.
Спрашивал их, почему не PostgresQL, вот и.
no subject
Date: 2010-09-21 07:01 am (UTC)базовый набор на постгрес нормально встает. вон, у тутубалина на друпале сейчас блог, а уж как он мускуль не любит...
no subject
Date: 2010-09-21 07:05 am (UTC)А кто такой Тутубалин?
no subject
Date: 2010-09-21 07:08 am (UTC)русский апач.
no subject
Date: 2010-09-21 07:21 am (UTC)no subject
Date: 2010-09-21 09:16 am (UTC)Кроме того, есть чудо природы в виде blog.module - у меня этот модуль используется на двух сайтах LibRaw и на английском _иногда_ вылезает бага на тему "если у вас select distinct и order by то в Select должны быть все колонки, которые в order". Тогда лезу руками и правлю код, матерясь. Потом апдейт это место сносит.
А в русской версии того же сайта я этой баги никогда не видел, хотя сайты ведутся синхронно.
Т.е. да, все работает, но поипацца временами приходится. Все-таки то, как индусы на MySQL пишут - это что-то.
no subject
Date: 2010-09-21 09:24 am (UTC)сломаютдопилят и модули перестанут вообще в базу ходить сами.no subject
Date: 2010-09-20 08:40 pm (UTC)no subject
Date: 2010-09-21 01:13 am (UTC)no subject
Date: 2010-09-20 03:14 pm (UTC)no subject
Date: 2010-09-20 07:41 pm (UTC)no subject
Date: 2010-09-20 07:52 pm (UTC)no subject
Date: 2010-09-20 08:17 pm (UTC)no subject
Date: 2010-09-20 08:20 pm (UTC)no subject
Date: 2010-09-20 10:17 pm (UTC)no subject
Date: 2010-09-21 04:44 am (UTC)no subject
Date: 2010-09-21 12:04 am (UTC)А все виденные мной порты / поддержки разных версий выливались в нечеловеческий геморрой и жуткий перерасход людских ресурсов в погоне за какими-то эфемерными целями, которых никто так и не достиг.
Не, я знаю, что можно аксапту на оракле поднять, а сап наоборот на mssql, но я не знаю, кем надо быть, чтобы втравить свою контору в подобную авантюру...
no subject
Date: 2010-09-21 03:49 am (UTC)В том смысле, что сменить её в рамках ваших технологий невозможно, но напряга нет...
no subject
Date: 2010-09-21 04:49 am (UTC)no subject
Date: 2010-09-21 05:06 am (UTC)В такой постановке вопроса это фетишизм.
no subject
Date: 2010-09-21 09:06 am (UTC)no subject
Date: 2010-09-21 09:16 am (UTC)Если есть какая-то (имхо, весьма сомнительная) выгода
делать такой продукт, чтобы работал со всеми базами, то...
Специализироваться конкретно под PGSQL&Oracle ещё не жутко сложно, ИМХО.
А вот если добавить сюды ещё какой-нибудь MySQL, тады ой ;-)
Да и звучит странно - "хотим под Oracel".
Вот "хотим то-то и то-то оптимизировать", например, звучит разумно.
Неужели знание Oracle (но абсолютное незнание PGSQL) тут перевесит?
Oracle ещё и денег стоит, гм, немножко ;-)
no subject
Date: 2010-09-21 09:27 am (UTC)no subject
Date: 2010-09-21 09:22 am (UTC)Раз уж я сюда пришел....
Понимаете, с процессорами оно совершенно аналогично - если хочется писать эффективный код, то его надо оптимизировать под процессор. И даже два почти одинаковых но с разным размером кэша - код будет разный (точнее, всякие константы в коде, отвечающие за working set)
Другой вопрос, что эффективность кода практически никогда не парит, все упирается в более медленные устройства.
Вот с СУБД оно проявлено просто острее. Ну несовершенны оптимизаторы и максимально эффективные запросы для разных СУБД будут разными (пусть даже оба исполняются). И вот с этим и жить. А если запросы разные, то значит весь db layer меняется и дальше на совместимость уже практически плевать, нету ее.
no subject
Date: 2010-11-02 09:01 am (UTC)