Уныние RDBMS

[metaclass]

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

Comments

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

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

[metaclass.livejournal.com]

Нет, наверно. Но ведь напрягает :)

[paranoekk.livejournal.com]

Ага, постоянно пугают этим, один раз только сталкивался, когда доисторическую Gupta меняли на MS SQL Server. А потом это превратилось в страшилки для непослушных джуниоров.

[zamotivator.livejournal.com]

+1

[korchasa.livejournal.com]

Ну код, бывает, используют повторно. А заказчики, бывает, хотят конкретную СУБД.

[chepikoff.livejournal.com]

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

[inhate.livejournal.com]

Бывает так, что если СУБД/Платформу нельзя сменить - покупается другой продукт.
С учетом полузаказной разарботки -надо быть готовым выполнить любой каприз заказчика не вспугнув его стоимостью портирования ;)

До фика ))

[shamanov.livejournal.com]

В компаниях, где я работал продукты поддерживают несколько баз данных. Геморой известный и понятный. Действительно приходится дублировать процедуры и прочее.

[inv2004.livejournal.com]

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

[kisa-i-osya.livejournal.com]

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

[metaclass.livejournal.com]

Я, кстати, продуктов на нем под виндой вообще не видел :)

[http://users.livejournal.com/_slw/]

ну всякие плагины ко всяким друпалам должны бы хоть две базы понимать

[http://users.livejournal.com/_slw/]

cisco unity express

[yurri.livejournal.com]

Потому и не меняют.

[permea-kra.livejournal.com]

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

[ennor.livejournal.com]

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

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

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

[esil0x.livejournal.com]

Пользователь коробочного продукта. ;))

[nivanych.livejournal.com]

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

[nivanych.livejournal.com]

Говорят, что к нему сейчас _реально_ только MySQL.

[metaclass.livejournal.com]

Сойду с ума, ибо даже Firebird+Postgresql уже вырывают мозг до основания.

[metaclass.livejournal.com]

Вопросы вида "хотим запустить ваш продукт на Оракле" возникают чаще.

[nivanych.livejournal.com]

Что-то тут не так.
В такой постановке вопроса это фетишизм.

[http://users.livejournal.com/_slw/]

а как же я?
как же оно на постгресе-то вот рядышком стоит? чего я не знаю?

[nivanych.livejournal.com]

> а как же я?

;-) А вот про вас-то и забыли!

> как же оно на постгресе-то вот рядышком стоит?
> чего я не знаю?

Вы что-то делаете не так! ;-)

А если серьёзно, то я сам не пробовал, слышал от товарищей.
Так что, таки под постгресом друпал нормально работает искаропки?
И не надо ничего допиливать?

[http://users.livejournal.com/_slw/]

ну я поставил.
специально ничего не пилил.

может ты перепутал? из последнего movable type постгрес вынесли.

[nivanych.livejournal.com]

Может быть.
Я ссылаюсь на слова товарищей, которые сейчас пользуют друпал и MySQL.
Если мне с ними придётся работать, то придётся и с MySQL связываться, который я не люблю.
Спрашивал их, почему не PostgresQL, вот и.

[http://users.livejournal.com/_slw/]

ну или врут или модуль какой особо извратный

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

[nivanych.livejournal.com]

Хорошо, буду знать, спасибо.
А кто такой Тутубалин?

[http://users.livejournal.com/_slw/]

lexa.ru

русский апач.

[nivanych.livejournal.com]

А, вспомнил, спасибо.

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

Это ж часто встречается. "Есть технология А, которая очень хорошо подходит, но мы знаем только технологию Б и будем ее использовать".

[nivanych.livejournal.com]

Ну что ж.
Если есть какая-то (имхо, весьма сомнительная) выгода
делать такой продукт, чтобы работал со всеми базами, то...
Специализироваться конкретно под PGSQL&Oracle ещё не жутко сложно, ИМХО.
А вот если добавить сюды ещё какой-нибудь MySQL, тады ой ;-)

Да и звучит странно - "хотим под Oracel".
Вот "хотим то-то и то-то оптимизировать", например, звучит разумно.
Неужели знание Oracle (но абсолютное незнание PGSQL) тут перевесит?
Oracle ещё и денег стоит, гм, немножко ;-)

[alextutubalin.livejournal.com]

Но, надо сказать, я там довольно много допиливал. И два своих патча для core - не вижу там и до сих пор руками накладываю при апдейте. Другой вопрос, что может они не нужны уже, не проверял.

Кроме того, есть чудо природы в виде blog.module - у меня этот модуль используется на двух сайтах LibRaw и на английском _иногда_ вылезает бага на тему "если у вас select distinct и order by то в Select должны быть все колонки, которые в order". Тогда лезу руками и правлю код, матерясь. Потом апдейт это место сносит.

А в русской версии того же сайта я этой баги никогда не видел, хотя сайты ведутся синхронно.

Т.е. да, все работает, но поипацца временами приходится. Все-таки то, как индусы на MySQL пишут - это что-то.

[alextutubalin.livejournal.com]

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

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

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

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

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

[alextutubalin.livejournal.com]

Я очень надеюсь, что в семерке это окончательно сломают допилят и модули перестанут вообще в базу ходить сами.

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

Так он уже есть, Оракл.

[zakharchemodan.livejournal.com]

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