dbms_photoshop
зы. А в чем причина излишней скромности, чтоб не зарегаться самому? Никто ж не требует указывать ФИО.

Я очень увлекающаяся натура, могу встрять в срач на ПТ
потерять в пустую кучу времени.
Я в завязке, минимизирую поводы ввязываться в бесполезные для меня срачи.

kinky catdbms_photoshopБыло бы интересно встретить use-case, что вот мы перевели высоконагруженную OLTP ACID систему с Oracle на MySQL cluster и снизили стоимость владения на столько-то.
ну чудес не бывает, mysql cluster это все лишь mysql с параллельностью (партиционирование вроде там и так есть), плюс архитектурные недостатки всех sharing nothinig, когда надо что то собрать accross nodes, большой джоин например).

Офтоп
Оптимизатор Informix еще 15 лет назад великолепно делал правильные планы
по межнодовому джоину через дблинки и ничего лишенего по сети не ганял.
Я НЕ говорю что он панацея как СУБД , но оптимизатор у него по приличнее
современного ораклового .
Ораклу даже по прошествии 15 лет , после остановки развития Informix
до его стоимостного оптимизатора еще расти и расти.

-2-д0kshared nothing архитектура самое то.shared nothing это не архитектура, а ее отсутствие. Активно применялась, когда прямая связь была не по карману.

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

приблизительно так ...

AmKadд0kХно оптимизатор у него по приличнее
современного ораклового
А мне было бы интересно посмотреть примеры сравнения. Не холивара ради.

Когда то в информиксовской ветке, кажется под эгидой Дениса Журавлева
проводилось сравнение одинаковой структуры таблиц в оракле и информиксе
и сравнивались планы запросов от стоимостных оптимизаторов.

В работе мне часто приходилось сравнивать таблицы
на разных серверах я ганял left outer join через дблинк.
Информикс всегда работал в десятки раз быстрее.

Еще + информиксу , они индексы строит в тысячи раз быстрее не лазя
попусту в темп если оперативной памяти хватает
у него нет тараканов с http://dba-blog.blogspot.com/2005/08/pgamaxsize-hidden-parameter.html

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

NETClientд0kХИнформикс подхода куяк куяк и в продакшин не прощает в принципе.
Какой злой дядька, этот твой Информикс!

Поэтому он и сдох, не выдержал конкуренции от гавнокодеров на рынке труда.
Они вместе с Лари забросали его шапками

NETClientд0kХ,

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

особенно ОЛТП , с лост апдетами.
Разница меджу блокировчником и ораклом для ОЛТП
только в том что блокировочник ведет себя всегда в режиме
ораклового select .... for update
на всю транзакцию.


Попробуйте в оракле for update используя
where current of
закомитить запись и сделать следующий фетч.
Привет ORA-01002

Если вы комитетесь в курсоре и не используете
where current of
то за первым же комитом внутри цикла
вы слетаете с блокировок и хваленой оракловой
консистентности в говнокод.

NETClientд0kХс лост апдетами.Я и слов-то таких не знаю.
д0kХfor update используя
where current
И такого в продакшене никогда не использовал.

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

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

NETClientд0kХРазница меджу блокировчником и ораклом для ОЛТП
только в том что блокировочник ведет себя всегда в режиме
ораклового select .... for update
на всю транзакцию.Ты хочешь сказать что в твоем блокировочнике блокировка держится и после окончания select-чтения до момента фиксации или отката транзакции?

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

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

Поищите по форуму , очень интересное чтиво , о
вычислении алгоритма автоматического рестрта транзакций в оракле разных версий. :)

Люди из мира блокировочников не срутся пытась понять что же там
начудили подчиненные Лари, а предсказуемо рефакторят свой софт.
Я понимаю, что посраться на форуме интереснее чем работать.

NETClientЯ-то всегда по своему наивному говнокодерству считал, что блокировочник вешает блокировку только на время чтения для обеспечения согласованности данных.

Блокировчник вешает блокировку на всю глубину транзакции
и даже дальше если ему это сказал программист.

Оракл по умолчанию никак не гарантирует согласованность
данных между несколькими запросами внутри транзакции.

Только одним джоином на транзакцию в for update курсоре с изменением
по where curent of или переходом в сериализейбл, что совсе грустно для
много пользовательского режима.

Если программист в оракле работает по другому , это аналогично
режиму грязного чтения в блокировчнике.
Вся проблема в том , что когда возникает неконсистентность изза
ораклового глвонокода , ее
не возвращают программистам в виде бага , а затыкают в саппорте приложения.