Всегда было интересно узнать, что народ думает вообще про PostgreSQL ? Мы на нем e-commerce сделали. Или все вокруг Oracle ? А деньги платите ? Или это проблемы клиента ? А не лучше ли продать комплекс, то есть СУБД+ПРОЕКТ, тогда за счет бесплатной СУБД можно и конкурентов отбить и себе денег забрать, а не платить Oracl-у. Все это при условии, что вам достаточно возможностей PostgreSQL.

Вообще рассуждения конечно простые, но общая идея я думаю ясна.

P.S. Если есть вопросы и предложения по работе в Питере по PostgreSQL - пишите xsov@mail.ru, вышлю резюме.

There is also open source enterprise level database SAPDB.. www.sapdb.org

Да как тебе сказать, Saper. Вот переводим всю e-commerce с Oracle на PostrgeSQL (7.1.1). По причине не только денежным.

А возможностей у PostgreSQL действительно предостаточно. Сейчас ее тестирую и сравниваю с Oracle - не enterprise эта ДБ пока.

Но работать можно. Если часто делать backup.

Конечно, Oracle самая приятная база данных из всех. Но заставлять покупать заказчика ее ради своего проекта мягко скажем неправильно. Можно лучше малость еще поработать и сделать все на PostgreSQL. Сложнее, конечно, но 90% проектов работать будут и на ней отлично.

2Korwin: поподробнее бы рассказал -- чем, собственно, не enterprise?

Сравните PostgreSQL с MySQL... (вопрос) ?

"Сравните PostgreSQL с MySQL... (вопрос) ?"
как можно "сравнить жопу с пальцем"?!!
MySQL система совсем не того уровня...

2Korwin: :) А backup PostgreSQL делает ой как шустро, по сравнению с теми же Oracle, MS SQL. Да и создание новой БД не проблема по времени - всего 5 минут, а не 30, как Oracle. К тому же Oracle для разворачивания пространства под БД в среднем (для одного и того же проекта) займет 1Gb(!), а PostgreSQL всего 5-10Mb.

А в чем не Enterprise - правда интересно. Репликация есть ... вроде (сам не проверял). Коммерческая поддержка тоже есть - www.pgsql.com, причем там различные схемы поддержки, да и партнером можно стать, их там тоже несколько видов.

Никто не хочет в России начать продвигать PostgreSQL как партнер Pgsql Inc. ? Я бы с радостью влился бы в это начинание, если только оно будет нормально сделано, с оплатой труда.

А вот в оплате труда, думается мне, и будет главная проблема. Продвигайте лучше Microsoft.

Не, серъёзно интересно, в чём posresql не-энтерпрайсный? Я вот с оракулом начиная ещё с шестёрки работаю, все его версии/релизы вплоть до 8.1.7 видел, и много-много с ним "ковырялся" -- его я достаточно хорошо знаю, включая массу слабых мест и ошибок. Но с постгресом не сталкивался. Когда я про него (postgres) читал, мне кое-что понравилось (например, его общая аккуратность, пример которой -- языковая поддержка (имеется в виду язык программирования) -- прописал, что такой-то язык такой-то dll-кой обрабатывается, и он есть. Это в противовес к ораклам, которые *всё* норовят в базу запихнуть, и без той же явы (которая у нас не используется) уже ничего не работает, а ресурсы она жрёт немерянно). По набору фич постгрес даже похоже и переплюнет ораклов -- дело в том, что масса того, что якобы умеет оракл, есть только в виде галочки, пользоваться этим на практике либо очень сложно, либо просто невозможно (ту же репликацию (правда, довольно замороченный случай) пришлось в конце концов на перле делать вместо ораклового replication api!). Не, я понимаю -- partition tables, optimizer, всякие data warehouse support и прочая для *больших* баз -- здесь да, postgresql не тянет. А в остальном? А надёжность, восстанавливаемость? (мне тут пришлось столкнуться с corrupted index в оракле -- ой, мама!, что я только с ним не делал! -- ни в какую, падает оракловый сервер и всё, и 8.1.5, ш 8.1.6, и специально попробовал 8.1.7 -- падает. Не знаю уж, почему этот индекс "испортился", но вылечить его удалось только перезагрузкой всего табличного пространства -- день на выгрузку, ещё день на обратно...)

Да, по поводу вышесказанного - saper (*) (2001-05-10 01:19:55.0). У меня на PIII-700 оракул базу генерит примерно минут 5..6, вместе с парой 10G-табличных пространств, и ещё столько же начальный дамп приложения грузит (размером ~25M) -- так что вроде скорость сравнимая. Не знаю, правда, как на этой машине postgres будет вертеться. На счёт бэкапа -- тоже вроде-бы жаловаться не приходится: если на локальной машине, то impортится примерно 1G за минут 30, а если ещё сказать direct=yes, то будет меньше 10 -- это сравнимо со скоростью копирования файлов. Кстати, бекапы импортом больше делать не рекомендуют -- там специальный тул появился. Я бекаплю файлы базы (раз в месяц или чаще) и журналы (archivelog) -- при таком варианте пофигу, с какой скоростью сами оракла бекапятся. На счёт объёма, занимаемого базой -- да, оракл любит много дисков, но не настолько -- у меня дома (P-160 MMX, 32Mи) стоит 8.1.6 под линукс, и "игрушечная" база (два табличных пространства -- system и temp) занимает 96 + 32 мега. Там, конечно, данных "не много", но во всяком случае этого достаточно за уши для самого оракла.

2 saper.
"А backup PostgreSQL делает ой как шустро, по сравнению с теми же Oracle, MS SQL." Только не надо это говорить про все версии. 7.0.2., например не могла восстановить данные из своего же backupа который был сделан 5 минут назад. Правда у 7.1.1. этих проблем нет :-)

"Да и создание новой БД не проблема по времени - всего 5 минут, а не 30, как Oracle."
Не забывайте, что Оракл не просто создает БД, он подготавливает файловую систему для ее работы плюс еще маленькую тележку по оптимизации данных. Чтобы потом часто не пришлось анализировать индексы.

"К тому же Oracle для разворачивания пространства под БД в среднем (для одного и того же проекта) займет 1Gb(!), а PostgreSQL всего 5-10Mb." Ну эта цифра очень загнута. Реально Oracle заберает дискового пространства не намного больше чем PostgreSQL. Это могу сказать точно, поскольку уже переносил ДБ с Оракл на PostgreSQL. Все дело в том, как поставить ДБ и дать правила расширения в Oracle.

"А в чем не Enterprise - правда интересно. Репликация есть ... вроде (сам не проверял)."
А как на счет кластеризации - то, что называется Parallel Server?
Репликация работает отлично с "плоскими" таблицами. Если используются отношения многие-к-многим или многие-к-одному, то тут не все так гладко, хотя обещают в ближайшее дело исправить.
А как на счет полной поддержки SQL92/99? Когда переходишь с одной ДБ на другую, это не только перенос данных, но основная работа - изменение приложений-клиентов если ДБ отличаются SQL синтаксисом. Что в данном случае очень существенно.

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

Вы не подумайте, что я противник PostgreSQL, как раз наоборот, но вынужден сначало проверить эту ДБ прежде чем на нее переходить.

А выводы такие, что она хороша и с каждой версией становится все лучше и лучше.

Сейчас 7.1.1 действительно можно использовать как enterprise. И документация появилась нормальная.

Основные минусы PostgreSQL

1) Нет возможности on-line backup'а - чтобы все транзакции писались в журнал с возможностью последующего востановления без потерь с полного dump'а и журнала (обещают сделать в 7.2)

2) Проблемы оптимизатора при поиске по нецелым полям (например по датам), плохая оптимизация подзапросов и совсем никакая оптимизация при работе с VIEW.

3) Нет репликаций

4) Стандартные утилиты не умеют backup'ить BLOB'ы.

5) Плохая производительность в случае частых update запросов из-за слишком "прямолинейной" реализации multiversioning.

А как дела в PostgreSQL с такими вещами как PIPE?
Как дела обстоят с хорошей оболчкой разработки вроде PL/SQL developer, SQL Navigator или TOAD?
Печально, как известно....
Потом доступ из Windows только через ODBC драйвер. Разубедите меня, если это не так.

Вот поэтому и не Enterprise...

Ответы всем по их замечаниям для PostgreSQL

Работал с Oracle 8.1.6.

1. Java в Oracle - действиетльно не радует, хоть это и облегчает перенос для разработчиков Oracle, но все же ... тем более они используют какой то странный JRE, работают только определенные версии.

2. Я больше месяца искал (только начал заниматься Oracle), как его поставить на Slackware - его легкая заточенность под RedHat не радует, но это не проблема, лишь бы включили основные моменты в FAQ (это я про те же gawk и free, и еще dbstart). Если это изучил - дальнейшие проблемы такого рода решаются быстро. К тому же это можно отследить по логам. Да и в последней версии говорят эта проблемы уже решена.

3. Насчет фич Oracle - не могу точно сказать, насколько важно для PostgreSQL наличие своих Warehouse ... но проблем с производительностью мы на нем не испытывали, в отличие от Oracle, и даже более того дисковая подсистема (Mylex AcceleRAID 170 128Mb) нас вообще не беспокоила, при 256Mb и Dual P3-933 никаких проблем с диском не было (Все под Linux Slackware 7.1 с ядром 2.2.18). Однако для увеличения производительности (в нашем случае) необходимо было увеличивать число процессоров (это я насчет SMP в PostgreSQL, которой там нет, то есть он все перекладывает на SMP ядра и для каждого соединения выделяет отдельный процесс, а ядро его уже распределяет на тот или иной процессор). При этом хочу отметить, что для Oracle важнее дисковая подсистема, а не процессоры (важность объема ОЗУ я бы оценил для обеих СУБД как одинаковую), ведь в Oracle очень хорошая multithread ...

4. Что касается тестов - то 30 минут для Oracle 8.1.6 и 5 минут для PostgreSQL 7.0.3 получены на AMD Thunderbird 800/384Mb/UDMA100. Для системы с RAID-контроллером в режиме RAID-5, а тем более для RAID-0 я уверен эти показатели могут и приблизиться. В любом случае PostgreSQL создает БД и пространство под БД прямо "на глазах" за какие то секунды, а вот Oracle - тут можно сходить попить чайку.
Дамп одинаковой БД во времени в PostgreSQL происходит раз в 10-50 быстрее, чем в Oracle.

5. Насчет качества backup - да, согласен, что backup 7.0.x версий приходилось доворачивать - но это было несложно (всего один скрипт). Это скорее временное явления (как вы сам заметили в 7.1 уже исправили), а не патология. А вот патологией я бы назвал стремление Oracle все засунуть в свою СУБД, ну просто все, что только можно и JVM, и фишки-рюшки, которые только 10% клиентов действительно нужны. И еще мне не нравится скорость и большие объемы баз в Oracle, хотя это напрямую зависит от задач и возможностей СУБД ... PostgreSQL, например, пока не может назначать права на записи в таблицах, хотя через RULE-механизм я это решил.

6. Что касается файловой системы, которую готовит Oracle при создании пространства под БД: а я никого не просил делать там FS, я даже не просил оптимизировать (то есть может можно как то такое отключать ? как в Informix например). К слову в PostgreSQL команда VACUUM ANALYZE выполняется раз в 5 быстрее, чем создание БД в Oracle с ее оптимизациями на будущее.

7. Насчет размеров БД - а размеры простые - по умолчанию, что было, то и поставил ... может это и не правильно ...

8. Parallel Server - как уже описал выше (п.3) PostgreSQL выделяет на соединение один процесс ... улавливаете ? MOSIX ! Далее вроде понятно, к тому же 1000BaseFX на второй сервер кластера и все. Или я неправильно трактую Paraller Server ? Если это связано с непрерывной репликацией, то по-моему rserv уже есть (есть еще вторая утилита репликации userv(?)), только я его не смотрел - поэтому загадывать не буду.

9. SQL92/SQL99 - тут действительно все не так гладко, согласен. С каждой версией они стремятся к совместимости, но не очень :) PostQUEL им больше нравится, он соотвествует их математической модели.

10. Скорость работы - уверен, что разница будет огромной (особенно, если отключить fsync :) ). Если измерять полный цикл - от установки СУБД, до ее первого backup/restore. Вспомним, хотя бы то, что необходимая часть PostgreSQL 7.0.3 умещается на одну дискету в архиве ...

11. >> и документация появилась НОРМАЛЬНАЯ ???!!! Вот уж чего не понял, так этого ... Документация к PostgreSQL всегда была на высоте с тех пор, как я с ним работаю (с версии 6.4.2). Хотя на полноту и достоверность она не во всем могла претендовать. Но неужели доки Oracle соотвествуют действительности на 100% ??? По крайней мере ошибок из-за неправильной документации у меня не было.

12. 2maxcom - 1) по моему придирчиво очень, хотя согласен, что где-то кому-то это может быть и нужно.

13. View оптимизированы, это точно - там же RULE-механизм внутри, а это значит, что план для него готовится заранее и хранится в базе.

14. Репликации есть - см. выше, хотя и не доделанные, но кому-то может и этого хватить.

15. Если я правильно читал TODO, то в 7.1 BLOB-ы или LO уже дампятся - смотрите ключи к pg_dump, а для 7.0.x в contrib лежал дампер LO, который легко можно было прикрутить к pg_dump скрипту или написать свой pg_full_dump.

16. В плохой производительности вините проектирощика БД, хотя в чем то тыточно прав. Вместо TRIGGER используй RULE - где возможно, и точно будет быстрее UPDATE.

17. Среда разработки - Sybase Data Architect 6.x - 7.x модель Oracle.
Про pgaccess упоминать не буду :)

18. Доступ из Windows - не только через ODBC, но еще и через libpq, при чем я для себя сделал патч для поддержки crypt-аутентификации, а потом сделал патч для libpq для хранения и передачи паролей через crypt в MD5-виде. И еще: ODBC дает доступ из BDE.

P.S. Я ни в коем случае не хочу поднимать волны флейма, криков по поводу PostgreSQL vs Oracle.

P.P.S. Всегда помните, что результаты моего тестирования только для нашей задачи, для другой БД с другой структурой все может меняться.

Работал я на Postgres, сейчас работаю на Oracle. Что могу сказать - если в процессе освоения Postgres я испытывал все новые и новые разочарования, то Oracle мне все больше и больше нравится. Postgres был совсем никакой для задачи типа DataWarehouse с вставкой ок. 2 млн. записей в день и периодическими отчетами по всей базе. На том же железе Oracle такой нагрузки просто не чувствует. Интегрированная JVM и JSP/Servlet Engine очень облегчают жизнь мне как разработчику - я просто пишу всю бизнес-логику на Java, а user interface на JSP.

господа да вы че? совсем офигел народ от весны.... сравнивать postgres с oracle.... давайте еще и db2 с mysql сравним до кучи.... кому надо два селекта три прихлопа -- пожалуйста.... oracle система совсем другого уровня... да что там.... а enterprise manager у postgres есть? и тд и тп

2maxcom. Вы уважаемый здесь специалист. К тому же Ваш сервер, насколько мне известно, работает под PostgreSQL. Расскажите, пожалуйста, свое мнение по поводу этой ДБ, ее конфигурации, нагрузке, проблемах и как вы их решали. По моему это многим бы помогло определиться с выборов ДБ для своих проектов.

Заранее спасибо.

Нда... Сравнили... Не, мне правда интересно, о каком энтерпрайзе тут может идти речь? Представьте задачу учета тел. разговоров, это ~1.5-2.0 млн. записей в день. Задание на дом: Проверьте, как скоро скрутит ваш постргес(через сколько дней).

BUG IN POSTGRESQL 7.1.1 ON FREEBSD

Тестировал эту Базу Данных на Линуксе. Все пучком. Решили тестировать на сервере и если все удачно, то на нее переходить.
Сервер на FreeBSD 4.2
ДБ ставилась из тех же исходников. При компиляции никаких проблем не было. Но появились глюки с timestamp:
create table tmp (create_date timestamp);

#insert into tmp values('2001-04-01 02:29:52');
INSERT 1021715 1

#select * from tmp;
create_data
------------------------
2035-05-29 01:33:36-05
(1 row)

------------------------
Если идет не 1 день апреля, то все пучком. Такой глюк на Линукс был в 7.0.2

Все. Как я разочаровался в этой ДБ. А ведь она мне так понравилась!! Хорошо, еще на нее не перешли. Пожалуй на нее можно будет взглянуть в версии этак 10, а пока все. Баста.

2Korwin: Там очень много опций для configure насчет локализаций, да к тому же есть переменные, в которых ты устанавливаешь формат дат: немецкий(русский), SQL, ISO ... У нас нечто подобное было, он просто твою дату неправильно интерпретировал, хотя то, что ты ему ввел меня удивляет, что он это принял. Твоя ситуация странная немного, поскольку ты ему вводил в его же формате. А вообще - во FreeBSD на PostgreSQL очень сильно рушались и разработчики и пользователи в списках рассылки. Поэтому попробуй под Linux.

Что касается учета телефонных разговоров и таблиц с 2 000 000 записей - согласен, что в PostgreSQL с этим сложно, но я же писал сравнения для моей задачи, а не для всех. В моей задаче за год в самой большой таблице появлялось максимум 500 000 записей, пока мы до такого колирчества не дошли (300 000), но все работает без тормозов. А вообще хотелось бы действительно сравнить СУБД, а те, кто тут писал ничего конкретного не сказал, только то, что нету WareHouse ... Ну и что дальше ? Ну нету и нету ... Зато в PostgreSQL есть WAL !!! И поэтому Oracle отстой ! Думаю так нельзя писать. Давайте сравним. У меня если Oracle 8.1.6 остался - поставлю, тока вы киньте сюда, какие настройки ему нужны для optimal perfomance, чтобы потом не говорили, что я все специально подстроил.

2 saper. Ты не против если я с тобой на эту тему по электронной почте буду спрашивать?
Просто у меня ситуация довольно специфическая.
Босс хочет фрибсд и Оракл, но потом переходить на другую ДБ (лицензия дорого стала объодиться). Лично мне понравился PostgreSQL на Линукс, но начальника надо переубедить, а тут такие еще проблемы.

Может кто в курсе. FrontBase нормальная штучка. Стоит она своих денег?

Мой email: dederer-a@mail.ru

Виноват, не разобрался. С timestamp оказался не баг, а фича.
Просто сделал:
TZ=+00; export TZ

И все заработало даже еще лучше.
Беру все свои слова обратно.

"но еще и через libpq"

С libpq из виндов как-то неясно. Под цыгвином у меня многое не собиралось или падало. Нет никаких документов на эту тему? Все, что я нашел, касалось только серверов под НТ, а вот про клиентскую часть умалчивалось.

Последнему anonymous: Берете исходники с сервера (например postgresql-7.0.3.tar.gz). Распаковываете. Смотрите доки admin. Там написано, как при помощи обычного Microsoft Visual C собрать libpq и psql для Win32. Все. Сам собирал - были мелкие проблемы, у вас их может и не быть. Все собирается.

P.S. Доки - хорошая вещь, особенно качественные, как в PostgreSQL.

мега-супер доку просто.... с такими доками 80% фич являются недокументированными... и узнать о их существовании можно только из mail листов....

2Salavat D. Samigoullin: 80% - это 100%-ая неправда. Плохо читаете.