Comments 54
«Судите сами — компания EnterpriseDB предлагает аналогичную СУБД...»

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

«Кроме привлекательной цены, EnterpiseDB предлагает своим пользователям непревзойденное качество, отличную производительность, масштабируемость, надежность и безопасность. А с новой Postgres Plus Cloud Database компания готова выйти на рынок облачных вычислений.»

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

Я отлично понимаю, что это перевод, а не ваш пост. И я не собираюсь рекламировать тут оракл, конечно. Но хотелось бы найти ссылки на какие-то подтверждения таким словам, да.
Это про репорты, да. В движке СУБД оракл, я все же надеюсь, работают программисты несколько профессиональнее.
И вы верите в 20 миллионов человеко-дней? Даже если будет 1000 человек участвовать в проекте, это займет 54 года, это при том, что я не учитывал выходные и праздники. Да это чистейший бред.
В оракле по данным с педивикии работает 108 тысяч человек. Между 10-м и 11-м релизом четыре года разницы. Я не пытаюсь что-то доказать или опровергнуть, но видно, что при таких условиях это может быть правдой.
Ну да, львиная доля это тех. поддержка, внедрение и юр. отдел. Ну да, если тупо взять всех сотрудников компании. А если взять только тех, кто реально участвовал в разработке. Я так понимаю, что не стоит считать тех, кто косвенно участвовал в проекте, тогда придется добавить тех кто строил здание, кто ремонтировал канализацию, тех кто делает еду и все такое.

Я даже не верю в то, что 1000 работает над продуктом. И то, если 1000 человек работает над ораклом, то их пора разогнать, т.к. они лентяи.
Вот это очень рекламная фраза, да.
Вы как-будто первый раз видите маркетинговую бла-бла-бла. Этот материал рассчитан на не-техническую аудиторию, если вам нужна дополнительная информация — запросите её у EntDB.
Качество выше чем у оракла, которые на 11 релиз что-то вроде 20 миллионов человеко-дней потратили?
А сколько потрачено человеко-дней на PostgreSQL?
Вот именно это я и хотел бы узнать. Исходя из общего числа людей в EnterpriseDB — на допиливание может быть ушло и не так много.
Катамаран кувыркнул пр сильном ветре. Неприятное, но достаточно обычное дело для гоночных катамаранов-тримаранов.
UFO landed and left these words here
Катамаран на какой-то регате, спонсированный оракулом.

Катамаран завален, но завалить катамаран надо очень постараться. Это, наверное, символизирует
Комменты появляются быстрее мысли
/me записать обновлятся перед постингом
Это пример того что происходит с парусом если в оверштаг слишком резко войти :)
Да еще и на порывистом ветре.
Статья чуть более чем полностью состоит из маркетинговой водички, причём направленная на инвестора. Дали бы подробностей насчёт загадочной Postgres Plus Cloud Database. С удовольствием бы почитал на русском языке.
Дали бы подробностей насчёт загадочной Postgres Plus Cloud Database.
Так это, судя по описанию, обычный PostgreSQL, заточенный под работу в cloud. Ну, может быть еще с oracle-совместимостью, т.к. эта главная фишка enterprisedb.
А на каком уровне обеспечивается эта совместимость и легкость миграции, кстати? Вот у меня есть 300 хранимых процедур, написанных и оптимизированных под PL/SQL в 11gR2. Что мне надо сделать чтобы перенести это все под EntDB?
У EntDB есть какие-то тесты, которые смотрят на используемые функции и дают примерную оценку, на сколько легко можно будет перенести. Т.е. это индивидуально для каждого программного продукта и, безусловно, существуют случаи когда переходить с Oracle не целесообразно.
Статья чуть более чем полностью состоит из маркетинговой водички, причём направленная на инвестора.
Да. Это перевод с forbes.com и статья рассчитана на соответствующую аудиторию.
Как минимум в России, многим руководителям, не особо разбирающимся в IT достаточно услышать красивое и распиареное слово «Oracle», чтобы принять решение о внедрении продукта, не зависимо от качества системы, которая этот Oracle использует. «Нужно автоматизировать %department%!» «Давайте поставим X» «Нет, давайте поставим Y» «Что использует X?» «Mysql» «Нет, говно! Давай-те ка что-нибудщь на Oracle» и плевать что Х-система, развивающаяся десять лет и на практике доказавшая своё превосходство, а Y — использует Oracle, но написан студентами за пол-года и толком не оттестирован. Это же ведь Oracle!!!
Теоретически да — по базе судить о всей системе неправильно, но на практике студенты выбирают как раз Mysql, так что у озвученной Вами позиции есть определенные причины.
Люто плюсую! Мы производим прекрасный и весьма популярный продукт в своей отрасли. Но есть ряд клиентов, которые говорят «А какая у вас СУБД? Firebird?? Что за говно! До свидания.» Поэтому теперь новый продукт делается кросс-СУБДшным, исключительно в маркетинговых целях.
В двух конторах вообще печальный опыт был. Биллинг у телефонистов на paradox ещё, синие окошки и прочие прелести. Работал как часы, ни у кого и вопросов не возникало — всем нравился, вопросов ни у кого не было. Прислало управление свою программу — Oracle, клиент-сервер, Delphi… пол года ума дать не могли, и в конце просто забили уже, автоматизацию в Excel довершали. А в другой (жкх) — на XBase++ и dbf, с консольной графикой — тоже считало всю область, старовато, но работало и математика была вся — комар носа не подточит. Год назад пришли «маркетологи „Oracle, Windows, On-line“… до сих пор раком стоим.
И при чем тут Oracle, позвольте спросить? :) Если у разработчиков руки из задницы и/или посре распилив с учетом еще и оракловой лицензии денег не осталось чтобы нормально сделать работу — то это проблемы абсолютно конкретных структур и организаций. К Oracle не имеющих никакого отношения.

Что же касается Paradox и прочих FoxPro — клёво, конечно, что оно продолжает работать спустя 15 лет после релиза первой версии, но мы же понимаем, что вечно это длиться не может, и что консолидированная БД как-то все-таки более правильно в большинстве случаев, по сравнению с тысячами файликов на сотнях компьютеров.
Один 'бессменный высокий начальник', в одной бюджетной организации, повздорил с начальником рангом пониже небольшого отдела информатизации (который на протяжении 10 лет успешно апгрейдил и поддерживал автоматизацию документооборота и воспитывал вполне себе IT специалистов, даже в условиях низких зарплат), причина была банальна — в следствии глупости этого начальника, обсуждения и решения о внедрении очередных задач просто шли мимо него на более высокий уровень…

Так вот среди перлов этого обиженного начальника были, кстати безуспешные, попытки 'внедрения' абсолютно не подходящих решений, разработанных на стороне и не адаптированных под реалии организации (как и с любыми САП системами, их нужно пилить под заказчика), тем более при успешной живой и развивающейся системе, уже решающей необходимые задачи… как результат конфликта — разбежавшийся отдел информатизации, полное прекращение разработок чего-либо, и медленная деградация автоматизации во всей организации и возврат к бумажкам… SAP R3 кстати так же 'пытались внедрить', все действия что были предприняты — это тупо пропилены бабки.

Oracle закупался на миллионные контракты так, что сервера стояли по 4-5 лет (думаю до сих пор стоят) ничем не занятые и уже морально устаревшие. Параллельно закупили IBM DB (вдумайтесь в смысл), так же думаю никем не тронутый,… при этом задачи вполне себе легко ложатся на PostgreSQL, не те нагрузки и не те задачи, что уже предлагаются решенными у Oracle.

p.s. это я к тому, что решения о выборе того или иного продукта в России принимаются даже не из маркетинговых соображений, а тупо по объемам попила… на mysql несколько десятков миллионов не по пилишь — шибко дешево, а вот на Oracle можно, там и простынки для отчетов уже маркетологами написаны.
Нет повести печальнее на свете, чем маркетолог в интернете.
Полез проверить есть ли что-то реализующее масштабируемость по принципу N-masters кластера. Т.е. прямой аналог Oracle RAC/GRID.
Вообще говоря, юзабили сайта (www.enterprisedb.com, я туда попал, правильно?) ужасное, потыкавшись на разные разделы я так и не попал куда-нибудь, где бы мне адекватно, по главам, представили документацию хотя бы в плане отличий от Postgresql.
Отчаявшись я ввел в гугл свой вопрос и все таки получил ответ на него.

2.4.5 Synchronous Multi-Master Replication

Postgres Plus Advanced Server does not offer this type of replication, though Postgres Plus Advanced Server two-phase commit (PREPARE TRANSACTION and COMMIT PREPARED) can be used to implement this in application code or middleware.

Это ваши слова, «Судите сами — компания EnterpriseDB предлагает аналогичную СУБД.»

Что вы в самом деле, фигню втираете. Да ладно бы где, здесь то зачем. Стыдно должно быть.
PostgreSQL имеет встроенные языки для написания процедур, в том числе совместимый (с оговорками) с PL/SQL
PostgreSQL имеет архитектуру сходную (с оговорками) с архитектурой Oracle

Нет речи про большую зелёную кнопку «Сделать хорошо». Речь о том, что переход с Oracle на EnterpriseDB будет значительно дешевле чем на, скажем, DB2 или MS SQL. Не понадобится всё переписывать с нуля.

Речь о том, что переход с Oracle на EnterpriseDB будет невозможен, либо очень дорог из-за того, что многие годами работающие вещи придется переписывать на коленке на стороне приложения, либо делать middleware, а это еще одна точка отказа, которая в свою очередь потребует резервирования и цепочка потянулась.
Основная проблема состоит в непонимании ситуации. Под простые задачи, которые в состоянии выполнять
опенсорсные субд никто и не будет использовать Oracle, потому что это просто _очень_ дорого. А задачи, под которые объективно был выбран Оракл, требуют возможностей, которые предоставляет Оракл. И спрыгивать на что-то другое, пока это другое до дотянется до требуемой функциональности просто идиотизм.
А задачи, под которые объективно был выбран Оракл
А если Oracle был выбран не объективно? ;-)
Ну тогда, значит, он был выбран за откат реселлеру или по какой другой необъективной причине.

Конечно, в очень многих случаях тот же мускул отработает ничуть не хуже. В тех N % случаев, где он не отработает (обычно это сложная аналитика и HAC) надо внимательно посмотреть на то, что предлагает Postgres. Пока что, из цитаты ваше, предложение самому реализовать мульти-мастер репликацию на уровне приложения, звучит не очень заманчиво.
или по какой другой необъективной причине.
Если взять любой «очень средний» проект и спросить, почему для него выбран Oracle в 9 случаях из 10 вы услышите в ответ «Э? Ну а чо ещё?».
Если не сложно, не ради холивара, можете описать под какие задачи разрабатывался Oracle?

Сразу оговорюсь — я вебразработчик и некоторые вещи мне довольно сложно понять. Вроде как репликация есть и в мускале, и в грескэле, и в оракле.
select\update\insert\delete тоже везде есть (ну может чего-то нету в оракле — не пользовался им)
разновидности движков для таблиц — тут вроде тоже проблем нет.

Спрошу даже по другому, для каких типов данных предназначен оракл, и почему он чем он так ценен?

Заранее спасибо за ответ
Сразу оговорюсь, что даю вам не ответ, а лишь свои размышления.

Вы когда-нибудь слышали об крупных DWH, успешно реализованными под управлением MySQL? PG? Я лично — не особо. В новостной ленте постоянно всплывает информация об Oracle, MS SQL и DB2, а вот хранилища на PG,MySQL — не особо на слуху. Только сейчас, погуглив, я выяснил, что есть люди, которые задаются этим же вопросом, и что даже есть люди, которые им что-то отвечают.

Вы бы сами не побоялись под управлением этих СУБД консолидировать данные, скажем о продажах в пятиста крупных розничных магазинов в течении пяти последних лет, с целью получения аналитики вроде динамики изменения средней суммы чека, какой товар с каким чаще берут вместе, влияние сезонности на спрос по товару и многого, многого другого. Я, лично — очень струхнул бы. Предпочел бы проконсультироваться с вендором, поискать прецеденты. В случае с ораклом есть и именитый вендор, чье слово не стыдно «пришить к делу», на чье слово можно опереться, есть и множество прецедентов, которыми можно блеснуть в презентации перед акционерами. А в случае с тем же ПГ? На кого именитого сослаться, подкрепляя собственное решение?

Потому и получается, что когда мы говорим об DWH, выбор может пасть только на Оракл, MS, IBM и без всяких там откатов. Сеть изобилует сравнением решений для этих субд, на разных железных платформах, оставляя ощущение, что другие СУБД для этих целей просто никто не использует.

А дальше лишь вопрос лицензирования. Если уж мы приобретаем лицензию оракла для DWH, то зачем использовать что либо другое для всего прочего? Тонкостей лицензирования я не знаю, но у нас в конторе никто особо не напрягается разворачивая новую БД под oracle database для новых решений в продакшн. Вроде как тем самым мы лицензионное соглашение не нарушаем.
Я бы подписался делать такой масштаб на Postgre. Заказав поддержку у какой-нибудь Postgre-поддерживающей конторы.
— То что Oracle — распиаренный бренд не дает гарантии оперативного закрытия багов
— Не дает гарантии что этих багов нет
— Неизвестно, может быть секономленные бабки лучше вложить в железо?

— И, достаточно наивно надеятся, что раз Oracle, значит не навернется. Лучше не молиться на такие верования, а придумывать стратегию бэкапа данных.
Вот про архитекттуру, сходную с архитектурой Oracle, это надо очень осторожно говорить. Потому что Лада Калина, в общем-то, имеет принципы работы очень похожие на Порше.
Если вы думаете, что только в этом отличия, то готов вас разочаровать. PostgreSQL отличная СУБД, но до возможностей DB2 и Oracle ей далеко еще. Хотя с другой стороны, вообще не факт, что они уж так прямо нужны.
Насколько я понимаю, наиболее близким аналогом Oracle RAC для PostgreSQL является Postgres-XC, но он пока ещё далек от 1.0.
> В конце декабря компания Oracle сообщила о падении своих акций на 9%.

В свете того, как за прошедший год упал Доу-Джонс, падение на 9% следует считать довольно неплохим ростом.

Я уж не говорю о том, что падение акций может быть вызвано совсем не качеством работы компании, а, например, покупками, или прочими непрямыми причинами, и делать вывод только из одной цифры «упала на 9%» бессмыслено.
мне кажется сейчас большая часть рынка оракл это комплексные решения, а не голая СУБД, так что предложить аналогичную или лучшую СУБД недостаточно
да, нужен стек решений, типа «лампы», но без «л».
пусть с борманом договорятся. хотя… наверное именно с ним не стоит
Да, но у тех компаний, которые захотят делать аналогичные комплексные решения или перенести свои существующие с СУБД Oracle есть возможность использовать Postgres с нормальной поддержкой и т.п. по в разы меньшей цене.
Видимо дело в том, что с Postgre принимающий решение менеджер не может получить откат.
Only those users with full accounts are able to leave comments. Log in, please.