LINUX.ORG.RU
Ответ на: комментарий от anonymous

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

anonymous
()

Postrges only!
Во-первых, вы уже работаете с ораклом, спецов переучивать практически
не надо, бо очень похожи.
Во-вторых, поверь моему опыту (если хочешь), Interbase - отстой. Он
подходит только для разработки несложных ученических баз и не
рекомендуется к использованию при количестве записей около миллиона.
Плюс проблемы при большом количестве клиентов. Кроме того не
поддерживает полностью стандарт SQLII, какие-то свои причуды. С
Postgres'ом проблем знать не будешь. Промышленный стандарт, своих фич
до фига. К тому же военным очень нравится, а они, сам знаешь, дерьма не
держат :-)))

random
()

Ny esli pod WIN to togda est echo SAPDB :-)

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

Ne Soglasen !!! Ti ne govoril chto "Но нужно сделать также вариант для тех, кто не готов платить."

Tak chto .... eto Glupi Vopros :-(

MfG

Nema russkoi Klavi :-) Ssorry

kred
()
Ответ на: комментарий от kred

В вопросе были явно указаны два варианта - postgreSQL и interbase. Т.е. начальное множество уже определено (в силу тех или иных причин).

Речи про oracle, mssql, mysql, sysbase или еще-что либо не шло. Поэтому и ответ - oracle (или sapdb) выглядит примерно как : q: что лучше - москвич или запорожещ ? a: мерседес :)

anonymous
()

Hy chtog ti Prav !!!

> "надо выбрать один для довольно важного проекта"
Ya prosto reshil pomoch :-)

Iz dvuch zol vibirayout menshee ,
"Postgresql" eto i est menshee ( dlya "UNIX" :-) )
"Select MIN/MAX/SUM ... GROUP BY" vsegda vizivayout "FULL TABLE SCAN"
Vremy ot vremeni neobchodim "VACUUM" (Potomy v systemach bez Adminov
nachinaet pritormagivat ...) + "rebuild index".

A ostalnoe "random" yge skazal. + "Poddergka SMP"


MfG

Konstantin

kred
()

При всех проблемах которые я видел у Постргесса, их все равно меньше ем у InterBase.
Главная проблема это плохой оптимизатор сложных запросов
Например
select * from table1 where id in (select other_id from table2)
Где (select other_id from table2) - возвращает значения от 1 до 20
будет работать намного дольше чем
select * from table1 where id in (1,2,..... 20)
Это проверялось на 7.2 До 7.3 руку еще не дошли
Причем все будет выполняться на одном процессоре, в то время как второй будет гулять

kka
()
2 декабря 2003 г.
Ответ на: комментарий от kka

вообще отимизатор действительно не блещет, но это компенсируется указанием плана выполнения запроса с правильно построенными индексами. а данный селект надо просто переписать без конструкции in (как и рекомендуется). dan

dan
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.