Ну а где не правду сказал? Ну ведь же пофиг на рубль, гривны, зайчики, зимбабвийские доллары. Ведь основные валюты USD, EUR, JPY, GBP, а если смотреть в этих валютах, то снизились.

поменьше читай обзоры бульварной прессы. цены снизились в долларах но не в рублях. с таким успехом можно смело заявить что почти все цены на отечественные товары снизились на 20%.

Ну да, вплоть до вида запроса этой самой даты. Таких мелочей там много наберётся.

> Я про админов и говорил.

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

> Ну да, но всё же это "силовое" решение. Можно кого-то и потерять, если конкуретны подсуетятся.

Вообще-то я сильно сомневаюсь, что бы хоть у кого-нить из 47K сановских enterprise customers бизнес сильно бы зависел от мускуля. Да и разговор-то простой: вы у нас купили продукт с поддержкой до такого-то года - до такого года мы продукт и поддерживаем. В дальнейшем будет только выпуск критических патчей для этого устаревшего продукта. Но вы от этого только выиграете, вот смотрите все наши эксперты в один голос рекомендовали бы вам перейти на Oracle, вот мы вам уже и профит высосали из пальца, вы только посмотрите как вы страшно обогатитесь.

> Ну по идее у правильно настроенного сервера с мускулем получается то же самое. И поддержку можно заказывать на стороне

Я в MySQL не разбираюсь. Вот недавно пытался создать базу в произвольном месте файловой системы и не нашёл как это сделать кроме как создать базу, а потом уже двигать каталок и симлинковать обратно. Так что у меня сложилось впечатление, что про файловую систему он мало чего знает, не говоря уже о том, что бы оценивать стоимость планы выполнения запроса с учётом характеристик носителя.

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

>Персонал, работающий с программами, написанными для MySQL? Дык для них БД вообще прозрачна. Админам да, придётся переучиваться.

Я про админов и говорил.

>А если им намекнуть о том какие перспективы с MySQL будут их подстерегать в будущем, когда поддержка устаревшей БД поставщиком прекратится?

Ну да, но всё же это "силовое" решение. Можно кого-то и потерять, если конкуретны подсуетятся.

>А что DBA там делать такого, чего нельзя автоматизировать и поддерживать удалённо? У Oracle даже размещением данных по дисковым группам Automatic Storage Management заведует. Бэкап опять же - можно делать по крону, например. Аппаратный сбой - в принципе почему бы человеку из техподдержки раз в сто лет и не доехать до кастомера поменять сгоревший винчестер-другой? Вместо того, что бы нескольким кастомерам держать каждому своего обслуживальщика базы даных, дешевле посадить одного такого на стороне Oracle обслуживать несколько кастомеров.

Ну по идее у правильно настроенного сервера с мускулем получается то же самое. И поддержку можно заказывать на стороне.

Какие прграммы? Испускающие серии insert/select/update-ов? Ну так им всё равно куда посылать запросы.

> персонал обучен.

Персонал, работающий с программами, написанными для MySQL? Дык для них БД вообще прозрачна. Админам да, придётся переучиваться.

> А тут что-то гораздо менее распространенное, пусть и более "крутое". Клинеты не начинают "с нуля".

А если им намекнуть о том какие перспективы с MySQL будут их подстерегать в будущем, когда поддержка устаревшей БД поставщиком прекратится?

>Ни персонала обслуживающего не надо, ничего - включи в розетко, нажми кнопочку "вкл" и стриги дивиденты.

> Неужели там всё действительно так красиво и удобно?:)

А что DBA там делать такого, чего нельзя автоматизировать и поддерживать удалённо? У Oracle даже размещением данных по дисковым группам Automatic Storage Management заведует. Бэкап опять же - можно делать по крону, например. Аппаратный сбой - в принципе почему бы человеку из техподдержки раз в сто лет и не доехать до кастомера поменять сгоревший винчестер-другой? Вместо того, что бы нескольким кастомерам держать каждому своего обслуживальщика базы даных, дешевле посадить одного такого на стороне Oracle обслуживать несколько кастомеров.

На мускуле технологии отработаны уже. Программы написаны, персонал обучен. А тут что-то гораздо менее распространенное, пусть и более "крутое". Клинеты не начинают "с нуля".

>Ни персонала обслуживающего не надо, ничего - включи в розетко, нажми кнопочку "вкл" и стриги дивиденты.

Неужели там всё действительно так красиво и удобно?:)

>И для пыха я не вижу проблемы сделать эмуляцию мускуля в таком хостинге, перенаправляя запросы в Oracle.

Да, такое можно, но это же получается мега-энтерпрайз-костыль. Проще начинку мускуля на оракл поменять, а интерфейс тот же оставить (хотя может и не проще).

Кризис всегда дефляция. Во время кризиса есть только одно выгодное вложение - деньги.

Во время кризиса нефть подешевела в три раза. Индексы упали на 30-50 процентов, жильё в Msk на 20 процентов, а в США с ценами на дома случился обвал. Ща всем нужна ликвидность.

Ну так новые побегут. Тем более в кризис, когда старые дохнут. К тому же если кризис - значит инфляция, значит если завелось немного наличности - надо её куда-нить вложить пока инфляция не съела. Купи себе ящик от Оракла с готовым бизнесом внутри. Ни персонала обслуживающего не надо, ничего - включи в розетко, нажми кнопочку "вкл" и стриги дивиденты. Такие хостинги будут дешевле имеющихся даже для мелких юзеров с их парой-тройкой веб-страничек.

И для пыха я не вижу проблемы сделать эмуляцию мускуля в таком хостинге, перенаправляя запросы в Oracle. Или просто нарисовать демон, который будет строить из себя MySQL-сервер и форвардить запросы в Oracle. С постгресом такие фишки не пройдут, а с Oracle - вроде должны бы.

C постгресом в последнее время был уже связан IBM.

Имхо большинство мелких и средних клиентов не будут ради замены мускуля бежать за новыми серваками от сана. Тем более в кризис. Если такое и будет - то процесс пойдет медленно и растянется на годы.

>Не знаю, много ли разработчиков сильно привязаны именно к MySQL, не используют уровни абстракции и т.п.

Конкретно в вебе - дофига и больше. Связка php+mysql считается настолько стандартной, что многие даже не знают о других вариантах (к сожалению). И хостинги почти все обеспечены мускулем.

Вот крупные клиенты могут перейти, это да.

>На крайняк можно озаботить унаследованных MySQL девелоперов написанием транслятора особенностей MySQL-вского диалекта для оракла и дело в шляпе.

Ну это можно постепенно соединять вместе легкую версию оракла и мускуль, оставив например старое название. Собственно, какая разница, как называется продукт. Просто направление развития будет немного другое.

Я не думаю что это для разработки новых приложений, скорее костыль под старые. Нормально там, где время отклика важно, используют трёхзвенную архитектуру с сервером приложений, который просто кеширует данные в том виде, как надо логике, не пытаясь строить из себя БД.

Вряд ли.. Но там наверняка найдётся что патентами затроллить.

Итого - Oracle становится полноценным конкурентом IBM у которой тоже есть свои БД, OS, железо и бизнес-приложения. Сервера приложений вроде тоже есть у всех. А Микрософт со своими поделками остаётся посасывать на берегу серверного мейнстрима, как врочем и все линуксовые вендоры потому что со стороны Oracl и IBM будет несложно затруднить им интеграцию со своими системами.

Да, HP не куплен ещё - на его месте было бы нехило самому прикупить себе немного постгресса и какого-нить интегратора типа редхата.

Это что-ли получается что это как раз одна из СУБДД "реального времени"? Интересно.

Хорошая придача к сановскому железу и солярке для него. Теперь Оракел будет впаривать клиентам опечатанные ящики сконфигурённые под их задачи со всем своим внутри. Зачем держать каких-то странных админов, когда можно взять в лизинг ящик и не париться о БД.

> Не думаю, что оракл сможет заставить всех поменять БД. Особенно учитывая инерционность рынка и привычки разработчиков.

Не знаю, много ли разработчиков сильно привязаны именно к MySQL, не используют уровни абстракции и т.п. На крайняк можно озаботить унаследованных MySQL девелоперов написанием транслятора особенностей MySQL-вского диалекта для оракла и дело в шляпе. А стандартный ANSI SQL уже поддерживается в Oracle (до девятки не было outer join-ов например).

A разработчики MySQL уже сейчас погрязли в многочисленных конкурирующих форках (http://developers.slashdot.org/article.pl?sid=09/03/30/228214), дезориентирующих пользователей и заставляющих разработчиков распылять усилия вместо того, что бы поддерживать единый поток разработки как это было раньше, до покупки MySQL-я SUN-ом

А разве постгрес имеет какое-то отношение к сану и ораклу?

У мускуля огромная клиентская база. Собственно, на каждом хостинге он установлен.

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

Oracle Database 10g Express Edition - Free to develop, deploy, and distribute (http://www.oracle.com/technology/products/database/xe/index.html)

Т.е. бери бесплатно и делай чо хошь, но есть ограничения функционала. Основные ограничения: 4Гб данных, 1 Гб ОЗУ, нет поддержки партиций. сравнение опций: http://www.oracle.com/database/product_editions.html

Далее, для мобильных и встраиваемых приложений - версия лайт: http://www.oracle.com/database/lite_edition.html

Для сверхкритичных ко времени отклика приложений - Oracle TimesTen In-Memory Database (http://www.oracle.com/database/timesten.html)

Втраиваемый (в приложение, типа sqlite если не ошибаюсь - никогда его не трогал) oracle - Oracle Berkeley DB (http://www.oracle.com/database/berkeley-db/index.html)

Т.е. базоданновые потребности рынка у них покрыты полностью, вроде как MySQL им без надобности.

Неа. Мускуль занимает совершенно другую нишу, и по назначению, и по стоимости. Это записная книжка с языком SQL, которая хороша для мелких-средних сайтов, где основная нагрузка - на чтение, а таблицы просты. Тут оракловская БД просто не конкурент из-за цены.

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

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