carper wessen автор
Oracle ...Достаточно один раз настроить, ну и вызывать раз в год, или три, специалиста "на помотреть".


сразу видно, человек в глаза не видел Оракла и не работал с ним.

Я тоже вас люблю :)

Мне, конечно, неудобно тут распинаться перед столь большим "специалистом", поэтому я повторюсь для других: требования к администрированию (и его сложности) ORACLE зависят целиком от возложенных на него задач и мало чем, по сложности, отличаются от таких же требований для других серьезных СУБД.

Для задач средней руки (но когда уже требуются многие фичи серьезных баз) ORACLE очень приятная база как раз с точки зрения стабильности и минимальной необходимости в обслуживании.
Да и нативная поддержка JAVA тоже кое-чего стоит для программиста на JAVA.
что жж. пофлудим :)
вначале я был с вами частично согласен :)
сейчас нет. мое мнение:
1) требоавния к администрированию баз данных (в абстрактном смысле) - одинаковые. нужно обеспечить по возможности оптимальную работу бд, и все :-) т.е.: установка, настройка (начальная), бэкап/восстановление, мониторинг, тюнинг, етц. но вот имплементации этих задач в рамках разных бд, насколько мне известно, - кардинально отличаются.
2) дальше. сложность задач администрирования различных промышленных субд (мс скл сюда не причисляю) мне, к сожалению, не известна. могу судить только по ораклу. в двух словах это можно описать так: копать и копать!
3) по поводу "Oracle приятная, стабильная и требующая минимальной необходимости в обслуживании бд"
а) приятная. полностью согласен
б) стабильная. да, но с большим количеством условий: "правильное" приложение, грамотное администрирование, использование "проверенных" технологий (на AQ например много жалуются), етц. и администрирование - это одна из неотъемлемых частей стабильной работы бд (и разработки тоже, если она еще ведется).
в) минимальная необходимость в обслуживании. да, можно вызывать ДБА на 1-2 дня в месяц. можно вообще не вызывать. можно иметь 4 сменных. чем выше должна быть доступность данных, тем важнее иметь в каждый момент времени человека, способного разрулить соответствующую ситуацию. вам не важны данные? тогда, конечно - вперед на мины с песней веселой.
4) нативная поддержка явы (имхо, конечно) - ява-девелоперу нахрен не нужна. она нужна частично администратору, DB девелоперу и в последнююю очередь ява-девелоперу (т.к. у него скорее всего есть апп. сервер )
зы. из пушки по воробьям не стреляют. хотя чего в этом гондурасе не встретишь...
ззы. на горбушку можно и не ходить, если есть анлим...

j-ora carperМогу описать другую типичную ситуацию: запуганные великим и могучим ORACLE нанимают на работу DBA, который успешно бьет балду почти 99% рабочего времени . При этом объяснет всем, что вам тут не 5-ть таблиц в 3-и строки, а целых тысяча - трепещите, без меня вам никуда. :)



Вот с этим я согласен. Без настройки не обойтись, но даже крупные проекты (500-600 пользователей) обычно не нуждаются в постоянном dba.
бред.
carperЯ попытался немного заступиться за ORACLE в выполнении того класса задач, где DBA нужен весьма редко. Раньше такие задачи просто старались не поручать ORACLE (т.е. не волнуйтесь, хлеб у DBA я не пытаюсь отобрать), сейчас это иногда весьма разумно.
пример?