Dooma
Oracle сильно проигрывает mssql-ю в удобстве и UserFriend-ливости.
На то он и MS, чтобы быть User friendly :)

Смотря что за User, и что за удобство. У Оракла тоже есть средства графического управления. Но настоящие базисты предпочитают все равно все делать на языке БД или с помощью консолевых утилит. На то он и язык БД, а они базисты.)
Все-таки плата некоторым неудобством за полное и глубокое управление не всегда кажется обременительной. Гораздо не удобнее, когда нажатие кнопок уже не помогает, а все что следовало за их нажатием не до конца ясно, чтобы понять теперь что надо предпринимать.

2 Dooma
Про базистов там не много с иронией. Все таки пацаны от БД, настоящие профи и лесорубы это слишком много горькой иронии нашего времени.



Dooma
В том же mssql этой "консоли" выше крыши и при желании все через нее настругать можно.
С ораклом знаком до 10-ой версии. Средства графического управления у Oracle на Java, поставляемые с сервером, мягко говоря, не катят против набора от MS, ни по удобству ни по функционалу. Поэтому и пользуют все сторонние утилиты.


Возможно. Не забывайте, однако, что Оракл то кроссплатформен. На платформе nix - катит, наверное больше, чем MS, потомо что последний там не катит совсем.





Dooma
Вы знаете, можно спорить по поводу:
- на сколько нужно ручками управлять SGA и т.п., когда есть хорошие механизмы автоконфигурации буферов в mssql или в DB2, оправдывающие себя на практике?



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



Dooma
- что заставило oracle (кажется, начиная с 9-ой версии) прийти к automatically free space management-у на основе bitmap-ов, когда у mssql и db2 это уже было давно?


Дальнейшее развитие системы- новые фичи.


Dooma
зачем нужно играть кучей hint-ов для оптимизации запроса на oracle


Причин много. Дело в том, что состояние БД все время меняется. У оракла тоже оптимзатор есть - и врядли, худший и постоянно совершенстующийся производителем. Но он оптимизирует, на основе определенной информации БД в определенном ее состоянии. Для наиболее глубокой оптимизации нужно собирать статстику по этому состоянию. А это может быть временеемкой операцией на больших обемах. И тут, конечно, есть варианты принудительно в задании проводить эту статистику через какое-то время. Либо для критических запросов заранее промерять такие плохие состояния и прописать тот хинт на все случаи. Или может быть вообще известна какая-то специальная инфа, которую в настоящей версии продукта оптимизатор не использует. И тоже хинты позволят это использовать. Возможны и еще какие-то ситуации.
Т.е. на хинты можно смотреть тоже как на дополнительную фичу по управлению. А не только по способу - его можно, наверное, и кнопкой впендюрить в каком-то тулсе.


Dooma
Я просто ни когда не понимал высокомерно-самодовольных клаворубов командной строки где надо и не надо, и тащащихся от собственной псевдозначимости DBA.



Я тоже никогда не понимал высокомерно-самодовольных не только клаворубов, но вообще. Я грил только про прагматический аспект. Лично для меня это все вынужденное. Т.е. я пользуюсь и кнопками время от времени. Но спокоен, если знаю что оно работает и с командной строки. Это чисто из опыта иногда не очень веселого.


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

Это скорей всего так. Вопрос только в том как мы вынуждены делать это в сегодняшних реалиях. Конечный пользователь - да, должен максимально легко получать инфу - наверное, максимально меньше набирая текста руками. Но для этого пользователь-разработчик должен париться, иногда пренебрегая каким-то комфортом. Ведь главная цель конечный пользователь. А то средства достижения этой цели.