В условиях когда один на мобильнике, а др. на суперкомпьютере.

Тёплое vs Мягкое

В каких условиях одно значительно круглее второго?

Началось... Оба СУБД, не?

Это talks, не?

> Оба СУБД, не?

FoxPro и Clipper тоже СУБД. Сравнивать с MySQL будем? :)

Намекаешь на говнистость? Зря. На мускуле кроме, да, половины говносайтов крутятся еще достаточно приличные вещи.

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

Ну вот я и спрашиваю когда одна СУБД работает быстрее другой, на каких запросах.

Пару лет назад в поликлинике наблюдал чудесную вещь - работу программулины на Foxpro для DOS.., и?:-) Если в базе 10 харь, и масштабирование им вообще никогда не будет нужно, им что обязательно мускуль ставить ?

Что лучше: SQL-блокнот или СУБД со встроенной операционной системой?

принцип «работает - не трожь» никто не отменял. Если вещь эта полностью решает все необходимые задачи, пусть решает дальше

Вспомнил как один кадр гнал на Oracle что там нет autoincrement )

> Ну вот я и спрашиваю когда одна СУБД работает быстрее другой, на каких запросах

От железа зависит сильно. Оракл очень продуктивно хавает оперативку. Но, оракал будет многократно быстрее мускула на любой задаче, если считать что обоим СУДБ хватает ресурсов. Скорость имеет смысл с постгресом сравнивать, MySQL - это что-то с кладбища.

MySQL - это что-то с кладбища.

4.2

> гнал на Oracle что там нет autoincrement )

Там его действительно нету. В постгресе, к примеру, есть оберточный тип serial который приводится к integer + sequence. А в оракле надо триггер before insert писать. Но большинство оракл-IDE уже имеют кнопку «New column with autoincrement». Триггеры пишутся на plsql, оракл прозрачно компилит весь plsql в java-байткод.

Триггеры пишутся на plsql, оракл прозрачно компилит весь plsql в java-байткод.

Зачем? Думал что он их так гоняет, на своих костылях.

s/оракал будет многократно быстрее мускула/оракл будет в десятки-сотни раз быстрее мускула/

Об будет быстрее на select * from my_table?

Постгрес гоняет свой plpgsql интерпретатором при каждом исполнении.

Оракл сильно на jvm завязан. Триггерные функции оракл компилит в jvm-байткод при создании. Естественно, исходный код на plsql никуда не исчезает, а сами plsql-функции можно писать прямо на жабе из консоли sqlplus.

Оракл будет быстрее на задачах продакшена за счет агресивного кеширования, множества различных изкоробочных оптимизаций и встроенного ИИ. Если вы часто исполняете этот запрос, то в оптимизатор оракла будет под него подстраиваться. Но, повторюсь, нужно нормальное ЖЕЛЕЗО. Сравнивать две эти две СУБД втупую бессмысленно. Базу оракла можно монтировать кластерно (tcp+fuse) как ФС, оракл обладает встроенным GIS и кучей прочих вещей. MySQL может нормально запуститься с базой в рамках на 100мб RAM и работать не падая каждую неделю, а оракл нет.

Мерседес или конь. Что быстрее?

Мерседес, там где он сможет проехать. Вот вам нормальный ответ без петросянства

Лучше бери postgresql и не парь мозг бородатым энтерпрайсом и мускулем. Потребление ресурсов у постгреса гибко настраивается, нет встроенного ИИ и джавы, есть куча экстеншенов, а главное не надо дорогущих лицензий, на надо держать армию мохнатых обезьян с сертификатами oracleDBA. И админ сможет крепко спать. А касательно логики-БД - в постресе хранимые функции можно писать на чистом С, если скорость их выполнения критична.

Какой к нему гуевый клиент хороший под линукс?

О том и речь, если что работает и работает именно так как надо и будет надо, зачем что то менять

К ораклу - бесплатный oracle developer на жабе.
К постгресу есть pgadmin3 (wxgtk), умеет большинство из необходимого. Но есть пара бесячих багов с русским языком из-за wx (в новых версиях wx вроде исправили).
И да, постгрес на большинстве задач сейчас не медленее оракла, это по личному опыту. Быстрее как в плане разработки базы под постгрес, так и в работе (GIS-запросы).

У меня Java+JPA+EclipseLink проект, потому думаю ни одного SQL запроса писать не прийдется. В чем могу выиграть от миграции?

С чего мигрировать на что?

С MySQL на PG

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

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

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

У проекта есть одна специфика. Это в универе и каждый год происходит смена поколений людей, которые с ним работают. И вариируется их уровень интеллекта...

>Триггеры пишутся на plsql, оракл прозрачно компилит весь plsql в java-байткод.

пруф?

Для работы с жабским ормом точно PG лучше, т.к. он лучше оптимизирует запросы. У нас на работе как-то переползли с mysql на pg (у нас тоже орм) и rps сайта поднялся на 20% процентов.

И да, gui к pg не нужен, ибо есть офигительнейший psql.

MySQl катит только как зрелая альтернатива NoSQL. Т.е. хочешь как NoSQL юзай - быстро, хочешь как SQL - терпимо.

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

>> Триггеры пишутся на plsql, оракл прозрачно компилит весь plsql в java-байткод.

пруф?

Личный опыт ковыряния в 11g, курения логов, оракловской базы и прочего.

http://wiki.oracle.com/page/Oracle+11g+Database+Features

Compilers
Improved native Java & PL/SQL compilers.

Scalable PL/SQL
The next scalable execution feature is automatic creation of "native" PL/SQL (and Java code), with just one parameter for each type with an "on/off" value. This apparently provides a 100% performance boost for pure PL/SQL code, and a 10%-30% performance boost for code containing SQL.

Под созданием нативного plsql тут подразумевают как раз то, о чем выше сказано. Это можно понаблюдать, написав кривой триггер, а затем посмотреть на ошибки компиляции/работы. Это будут те же ошибки, что выдает javac/jvm. Ну и бактрейсы в триггерах конечно же)

Это первая ссылка в гугле.

Это походу фича 11го оракла. С ним еще не работал.

А еще там нет boolean и money.

Там его действительно нету

нафиг он нужен, если есть секвенции?

К ораклу - бесплатный oracle developer

вроде уже не бесплатный

> нафиг он нужен, если есть секвенции?

Как в оракле сделать, чтобы значение БЕЗ before insert триггера считывалось из последовательности? В постгресе есть ALTER COLUMN ... DEFAULT = nextval(); или просто виртуальные типы колонок serial/bigserial.

Если в базе 10 харь - достаточно одной папки для бумаг.

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

Посмотрел JPA бенчмарки MySQL vs PostgreSQL. Мускуль сливает.

http://www.jpab.org/EclipseLink/MySQL/server/EclipseLink/PostgreSQL/server.html

ну извините, в условиях задачи о постгресе не было сказано. И да, я знаю, что мускуль сливает постгресу)

Только тот тест все таки для JPA, что сразу говорит, что БД может быть не при чем, есть еще вопрос в драйверах JDBC

> MySQL vs PostgreSQL. Мускуль сливает

Это и без теста было фактом. Ещё лет 5 назад.

>s/оракал будет многократно быстрее мускула/оракл будет в десятки-сотни раз быстрее мускула/
Даже для веба? Где запросы все простые и используются индексы?
А еще насчет ИИ, кэширования запросов. В mysql есть попроще конечно, но тоже query cache и встроенный optimizer. И партишнинг тоже кстати есть. Хотя руками попиливать надо больше конечно.

> В каких условиях один значительно быстрее другого и наоборот?

Всё равно, что сравнивать трактор с мотоциклом. По трассе мотоцикл быстрее, по говну — трактор.

Oracle ставится на такие сервера, на которых mysql выглядит как мусор в каталоге /tmp, и под такие нагрузки, которые mysql разрывают просто в клочья. Зато если у тебя в качестве сервера списанный десктоп и из нагрузки только десяток твоих коллег с trac'ом и bugzilla'й, то оракл с этим гарантированно не справится — будет тупить и тормозить

> В каких условиях одно значительно круглее второго?

Одно — пальто, другое — торт. Но это оффтопик.

> FoxPro и Clipper тоже СУБД. Сравнивать с MySQL будем? :)

Их преимущество перед MySQL — в отсутствии SQL. Сейчас это модно. И оперативной памяти мало надо. Триппер не пробовал, а FP сильно проигрывает MySQL в скорости на базах от десятков байт до 10 мегабайт. Крупнее тоже не пробовал.