Помнится, кто-то там приводил mysql как пример отличной открытой БД

[iskatel]

Компания MySQL AB объявила о разделении СУБД MySQL на два продукта - MySQL Enterprise и MySQL Community. MySQL Enterprise предназначен для коммерческого распространения и отличается от Community редакции распространением в бинарном виде, пакетом технической поддержки, наличием GUI
Если длительность цикла обновлений для MySQL Community урежут (с сегодняшних 5 лет), то это будет означать конец mysql как открытой БД для мало-мальски серьезных проектов, не требующих мощи Oracle.
Всё в этом мире стоит денег. Вот и манагеры из MySQL AB ркшили, что пришла пора активно стричь купоны.

Comments

[deka.livejournal.com]

Ну не везде ж Оракл ставить. Как-то глупо, по моему мнению, для скромной базы в пару гиг (а иногда и меньше) ставить Оракл, тем более, что их бесплатная версия сильно урезана.
Жень, ну что за детский параметр "размер базы", ей богу ;) Ну хотя бы TPS, и то уже ориентир. Я не спорю -- есть некоторые вещи, для которых мускль неплох. Например, даже оракла он переплюнет по скорости insert-ов (даже обычных, про delayed я и не упоминаю), и в задаче собрать много не очень критичной к целостности первичной информации для последующей агрегации -- гораздо интереснее оракла и по деньгам, и по производительности. Но если дело касается довольно сложных запросов с комбинациями join-ов -- увы и ах. И отладочные средства у него -- ну разве что explain, и всё.

А постгрес относительно хорош. Относительно 4-го мускуля. :)
Семёрка -- относительно четвёрки мускля, восьмёрка -- относительно пятёрки. Всё относительно ;) Постгресовцы раньше сделали упор на прикладную часть и целостность данных, сейчас занимаются полировкой рюшечек. Мускль сдедлал в своё время упор на скорость и стабильность базового engine (правда, его уже поменяли, но не суть -- новый вродь тоже стабилен). Сейчас мускль пытается догнать по функционалу постгрес, но пока отстаёт. К тому же появляются нестабильные выпуски.

Для примера

[iskatel.livejournal.com]

Когда в виде решения для хранения базы ТТ предлагается использовать _только_ Оракл.. нафиг такое решение. (HP OV service desk) Оно понятно для крупного колл-центра, но не для мелких/средних служб поддержки.

Re: Для примера

[deka.livejournal.com]

Ничего не могу сказать -- ни подтвердить, ни опровергнуть. Хотя состав средств для реализации задачи в техтребованиях -- бред, если только ТТ составляются не на базе имеющегося (скажем, у нас есть оракл и ресурсы для задачи, так почему бы его не использовать, в то время как ставить другую базу нерентабельно). Если решение с бюджетом в милионы зелёных рупий -- оракл катит. Не скажу за HPOV Service Desk, давно не следил за опенвью продуктами, но по моим представлением hpov -- это уже забюджетное решение для мелких служб поддержки. Так что если на hpov раскошелились -- кошеляйте дальше ;)

Re: Для примера

[iskatel.livejournal.com]

hpov хорош как средство мониторинга. (NNM) Дорог, правда.
Как решение для поддержки - ну очень дорого с учетом Оракла.

Хотя состав средств для реализации задачи в техтребованиях -- бред
Так манагеры ж наверняка сказали - есть договоренность с Ораклом, делаем под него.. впрочем, там где-тоу поминался MSSQL, но куда ж его воткнуть-то на unix машинах ?

Re: Для примера

[deka.livejournal.com]

Так манагеры ж наверняка сказали - есть договоренность с Ораклом, делаем под него..
Такое частенько вычислялось и за это больно билось. Причём аргументировано, с цифрой в руке.

Re: Для примера

[iskatel.livejournal.com]

Это что-то новенькое. В коммерческом ПО такое сплошь и рядом. Кто ж манагерофф бил-то?