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

> oracle неповоротливый монстр живущий своей жизнью не расчитанной на 100000 строк нового кода каждые 2 недели и слишком часто глючит на сложных запросах

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

no-dashi ★★★★★
()
Ответ на: комментарий от WindowsUser

>Какой плевок ораклу в лицо:

>-- No stored procedures;

>-- Only very simple triggers;

Это не плевок - это реалии.

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

Да, и еще в теории. :-)

PS. ИМХО не пишу принципильно.

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

>Ну почему же.... Есть такая вещь, как MenuetOS, написана на ассемблере, у нее даже графическая среда есть. :) :)

Это такой очень продвинутый дос. Я такие графические среды тоже когда-то на ассемблере писал, чтобы они быстро бегали (точнее саму графическую подсистему на асме). Если попробовать задвинуть какую нить высокоуровнувую фигню типа OLE туда - подозреваю автор задолбется писать/переписывать то, что есть. Проблема больших систем именно в том что они большие и сложные. Пока оно маленькое - не важно на чем оно написано - его можно менять как хочешь. Если оно обросло фичами, модулями, драйверами, апликухами - изменения (особенно архитектурные) даются очень дорого по времени и соответсвенно по деньгам. И потому требуются абстракции большего уровня, чтобы разбираться с такими изменениями.

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

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

Это спор не о чем -пиши ТЗ -я оглашу сумму.Если договоримся -найму людей и будет тебе кде на ассемблере :)

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

>Все эти сторед-процедуры, внешние ключи и т.д. и т.п. очень хороши на >пустой базе (учебной с одной, двумя таблицами).

>Да, и еще в теории. :-)

О мой моск!

Щас дал линк нашему dba -пусть посмеется.

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

> 1) Сколько Вам лет?
> 2) Озвучьте Ваш профессиональный опыт, желательно -- ссылкой на резюме.

18, и студент я, студент. Рецидивист, можно сказать ;)

Gharik
()
Ответ на: комментарий от no-dashi

>Не люблю оракел. Но в одном из последних инцидентов я для теста делал простенькую базешку из десятка таблиц и примерно столько же вьюх. Так вот если оракел с задачами такой сложности справлялся играючи, а mysql... Повис напервом же мало-мальски серьезно запросе.

Касается и anonymous'ов.

Я нигде не сравнил oracle с mysql, поэтому не нужно мне доказывать что из них лучше. Я просто высказал предположение, почему не смотря на многочисленные рекомендации опытных разработчиков делать как можно больше логики на стороне СУБД, eBay поступает наоборот.
Возможно, что по той же причине, по которой yahoo! использует apache без нитей, т.е. в больших проектах поддержка корректной работы сложных программ слишком дорого стоит. Чем проще, тем лучше.

По поводу "бреда" про opensource, покажите мне пример, когда реклама заставила кого-то использовать opensource программу против желания пользователя... С проприетарными программами это происходит постоянно. Есть конечно и другие причины выбора той или иной программы. Просто я хочу сказать, что часть возможностей oracle, существует в виде рекламы и реально никому не нужна.
Вспоминаю пример с пылесосом, у которого в feature есть пункт "Осушение воздуха в помещении" ;)

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

>почему не смотря на многочисленные рекомендации опытных разработчиков >делать как можно больше логики на стороне СУБД

Еще раз - логика в БД и большая скорость работы вещи несовместимые Хотите скорость -юзайте файлы

>Возможно, что по той же причине, по которой yahoo! использует apache >без нитей, т.е. в больших проектах поддержка корректной работы сложных >программ слишком дорого стоит. Чем проще, тем лучше.

меня терзают смутные сомнения но либо там не простой апач либо вообще что то свое ,выдающее Server: Apache

Потому что при их нагрузках -юзать стандартный веб-сервер это все же перебор

>просто я хочу сказать, что часть возможностей oracle, существует в виде >рекламы и реально никому не нужна.

А примеры можно?

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

>>почему не смотря на многочисленные рекомендации опытных разработчиков >делать как можно больше логики на стороне СУБД

>Еще раз - логика в БД и большая скорость работы вещи несовместимые Хотите скорость -юзайте файлы

Еще раз: почему НИ ОДИН сотовый оператор не использует MySQL или хотя бы Oracle без бизнес-логики внутри базы?

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

>Еще раз: почему НИ ОДИН сотовый оператор не использует MySQL или хотя >бы Oracle без бизнес-логики внутри базы?

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

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

>>Еще раз: почему НИ ОДИН сотовый оператор не использует MySQL или хотя >бы Oracle без бизнес-логики внутри базы?

>потому что там нагрузка меньще чем в поисковой машине.Я открыл для тебя америку?

Поисковые машины НЕ ПИШУТСЯ с использованием MySQL. Это во-первых.

Во-вторых, у биллингов сотовых операторов нагрузка в количестве транзакций если не в десятки раз, то разы БОЛЬШЕ чем у того же eBay.

Для справки, только по Москве и только у одного сотового оператора совершается порядка 120 миллионов звонков в день.

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

>Во-вторых, у биллингов сотовых операторов нагрузка в количестве >транзакций если не в десятки раз, то разы БОЛЬШЕ чем у того же eBay.

Разницу между запросом и транзакцией понимаем?

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

>Разницу между запросом и транзакцией понимаем?

Я-то понимаю. Это Вы, судя по всему, не представляете себе принципы работы сложных биллинговых систем сотовых операторов.

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

>Я-то понимаю. Это Вы, судя по всему, не представляете себе принципы >работы сложных биллинговых систем сотовых операторов.

Напиши stellar -он как раз в mail.ru работает -расскажи ему что лучше им с яндексом сделать хранилище индексов в оракле :)

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

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

> > 18, и студент я, студент. Рецидивист, можно сказать ;)

> Странно, я думал, не более 15....

То мой брат-близнец "e", в детстве болели с ним менингитом - он умер, а мне повезло.

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

> То мой брат-близнец "e", в детстве болели с ним менингитом - он умер, а мне повезло.

Неправильно. Менингит -- это страшная болезнь! От нее либо умирают, либо становятся дураками. Вот мы с братом болели, он умер, а мне повезло!

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

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

Потому что память дико голимо медленная? Или почему?

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

> они вычистили из БД все хранимые процедуры, оставив только простейшие запросы. Даже join делают сами, а не средствами БД. Зачем??

Легче версии кода контролировать и обновлять при помощи CVS.

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

> Но что бы кто ни говорил - лучше оракла еще никто ничего не придумал

Бред!!!

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

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

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

oracle кстати вряд ли глючит - у меня, к сожалению, нет опыта работы с ним, но вот презентации впечатляют. oracle это действительно монстр, и работает он в высокопроизводительных системах (кстати там почти всю базу в памяти держат - свыше 200 гиг памятию. найдите в сети слайды - Usenix '05 - Solaris Kernel - Performance, Observability & Debugging. внушает и кое-что объясняет.

а мускуль ваш у меня не смог сделать drop базы на 10 гиг в течении 20 минут (ради интереса уже ждал), причем в документации написно, что если не дропает - вы его прибейте, и удалите файлики ручками, а потом опять запустить.. ф топку. если уж open source - то postgresql - за три года проблемы ни одной с ним не было! :)

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

>где почитать про сильно тяжелые биллинги на мильены рыл? кластеры и >параллельные алгоритмы действительно становятся очень актуальны... но >вот, ради бога, только не надо мускулей..

На самом деле в случае оракла куда более актуально увеличение мощности железа на котором он крутится чем кластреризция тк все же оракл в кластере работает галимо (Oracle Streams штука все же очень глючная)

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

> Еще раз: почему НИ ОДИН сотовый оператор не использует MySQL или хотя бы Oracle без бизнес-логики внутри базы?

В-первую очередь, потому что им ее продали, тот же CBOSS. И основная бизнес-логики там на java-server, кстати.

После общение с несколькими разработчиками биллинга в России - основное преимущество Oracle для таких проектов - маркетинг.

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

>> Еще раз: почему НИ ОДИН сотовый оператор не использует MySQL или хотя бы Oracle без бизнес-логики внутри базы?

> В-первую очередь, потому что им ее продали, тот же CBOSS. И основная бизнес-логики там на java-server, кстати.

Не надо ля-ля. В CBOSS она на PL/SQL (хранимые процедуры + Oracle Forms) - bloatware ещё то. На Java 3 года назад не было ничего практически, были только потуги написать Веб-морду на Java, оставив логику на PL/SQL. Не думаю, что сейчас что-то сильно поменялось.

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

>Не надо ля-ля. В CBOSS она на PL/SQL (хранимые процедуры + Oracle >Forms) - bloatware ещё то. На Java 3 года назад не было ничего >практически, были только потуги написать Веб-морду на Java, оставив >логику на PL/SQL. Не думаю, что сейчас что-то сильно поменялось.

Я так понимаю что ты J2EE даже в виде рекламных проспектов не осилил?

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

Уверяю тебя что если тебе удастся хоть раз в этом сегменте успешно заменить оракл на mysql -к тебе клиенты просто побегут ,потому что им тоже не нравится платить 50к за оракл и еще 3к ежемесячно dba и админам для него.Это не говоря уже о дорогом железе и хреновой поддержке.

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

> порой проще разбивать сложные запросы, получая кучу id'шников, а потом делая запрос вида where <поле> IN (список).

Оно может и проще, но если я правильно понимаю, разбор запроса будет каждый раз производиться (реже будет использоваться library cache). Откуда и тормоза, и неэффективное использование памяти.

Vond ★★
()
Ответ на: комментарий от pitekantrop

> В CBOSS она на PL/SQL (хранимые процедуры + Oracle Forms) - bloatware ещё то. На Java 3 года назад не было ничего практически, были только потуги написать Веб-морду на Java, оставив логику на PL/SQL.

Ты наверно сильно удивишься, но похоже в новом продукте rtBilling Oracle уже нет :), потом сливают в него для датацентра. Кстати, один из крупнейших сотовиков в европе, тоже использует свою собственную систему для биллинга, затем уже отправляя данные для аналитики в Oracle.

Да, кстати, я не имею веду что там MySQL - там вообще нет SQL-я :)

fi ★★★
()
Ответ на: комментарий от anonymous

Кстати, насчёт использования БД в Google. Во-первых, очевидно что у них такая куча систем, что разных БД там тоже хватает.

Во-вторых, если не изменяет память, такая интересная вещь как Berkeley DB в кластерном варианте разрабатывалась для Google и совместно с Google.

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

>Во-вторых, если не изменяет память, такая интересная вещь как Berkeley DB в кластерном варианте разрабатывалась для Google и совместно с Google.

ну может список сотрудников хранят :) Но точно не в поисковой машине

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