Вышел первый релиз Oracle Database Express Edition

>А так как на PL/SQL можно написать практически все, кроме совсем специфических фич, типа системных, так что жаба в Оракле практически не нужна.

Я сейчас занимаюсь поддержкой и немного разработкой огромного проекта на оракл, который написан почти целиком на PLSQL (только серверная часть, но ОЧЕНЬ большая). Если коротко мое мнение об этом? PLSQL не годится для больших проектов (в смысле разрабатывать его только на plsql), потому что: 1. в этой куче просто структурного кода хрен разберешься; 2. очень медленно. Так что сейчас даже явные противники Java в нашей конторе, неохотно, но соглашаются, что нужно все переделывать на Java.

>Ищи ветки в которых перетираются проблемы c MSSQL+.NET. Причем тут Oracle с PLSQL, Java и MSSQL+.NET?

PS: Я одинаково отлично знаю plsql и java, и могу со всей ответственностью заявить, что использование plsql в oracle целесообразно, только, когда в коде процент sql запросов переваливает за 95% от общего кода... остальной код лучше писать на Java или для гурманов на C++.

Воистину товарищь!

А он и так поддерживал - надо было только из rpm сделать deb и немного с бубном поплясать ....

>>PS: Я одинаково отлично знаю plsql и java, и могу со всей ответственностью заявить, что использование plsql в oracle целесообразно, только, когда в коде процент sql запросов переваливает за 95% от общего кода...

Я что ты еще пихаешь в код, что у тебя становится соотношение SQL - PL/SQL например 50%/50%?

2scorp

у вас не кантора, а сборище ламеров, тебе уже сказали иди читай Кайта. Оракал никогда не позиционировал тормозной jvm как замена pl/sql, т.к. серйозную нагрузку jvm никак не потянет.

Саныч ты жжошь! Ай молодца! Мне быдлу весело мля ;)

Вылези из песочницы и посмотри вокруг.

> Это прежде всего, решение, которое позволяет совершенно легально отлаживать поддержку Oracle в своем ПО.

Не гони, для разработчика он и так легален.

>Я что ты еще пихаешь в код, что у тебя становится соотношение SQL - PL/SQL например 50%/50%?

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

>у вас не кантора, а сборище ламеров, тебе уже сказали иди читай Кайта. Оракал никогда не позиционировал тормозной jvm как замена pl/sql, т.к. серйозную нагрузку jvm никак не потянет.

А ты ее эту нагрузку подавал? Ты вообще хотябы в Concepts в Оракл заглядывал в раздел Java? Ты знаешь как организована jvm и ее сборщик мусора в БД Oracle? Если бы прочитал хотябы пару абзацев, то наверное так бы не говорил.

А Кайт заложник своего богатого опыта и привычек... Java ему учить лень... :-) Попробуй почитать не Кайта, а официальную документацию и ты очень быстро поменяешь свое мнение об этом человеке. ИМХО конечно.

Подскажите а есть чтото типа HTMLDB для мускула?

О!...

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

Я себе очень хорошо могу представить очень сложные проекты и нетривиальные бизнес-правила и дураков маркетологов тоже до кучи могу, но только это все не дает ответ на вопрос почему так пного PL/SQL кода?

> почему так пного PL/SQL кода?

Угу кстати интересно? Действительно что-ли явабыдлокодеры?

По идее все бизнес правила должны описываться в таблицах и обрабатываться с помощью SQL а не PLSQL.

У меня как раз такой случай был на работе, когда явабыдлокодер говорил что проще выбрать несколько десятков тысяч строк и обработать их в яве чем написать запрос на 40 строчек выдающий результат в 10 строк.

Мне рассказывали, как старых пердунов, писавших на коболе, в срочном порядке переучивали на пл/sql, видать еще не все ушли на пенсию.

Аффтар жжот! Лонг, пеши исчо! =)))

>Я себе очень хорошо могу представить очень сложные проекты и нетривиальные бизнес-правила и дураков маркетологов тоже до кучи могу, но только это все не дает ответ на вопрос почему так пного PL/SQL кода?

Во первых есть такое понятие как инерция мышления. Во вторых некоторые организации работают с Ораклом еще с 7 версии и у них уже есть штат plsql программистов, которых переучивать на Java дорого. В третьих некоторые люди, например, как ты дорогой анонимус, думают, что родной Оракловский plsql всяко лучше чем что то сторонее типа Java и не вдомек им, что Оракл свою jvm написала с нуля и специально под свою СУБД и что эта jvm тоже является для Оракла родной. Плюс к этому похожий на basic plsql выучить легче, чем ОО язык Java, но и отдача от них получается разная.

Сам я не против plsql и использую его достаточно часто, но всякому инструменту свое место и место plsql СЕЙЧАС для написания небольших блоков когда с подавляющим содержанием sql операций и очень небольшой алгоритмической нагрузкой на сам язык plsql.

>неужели ты думаешь что $50k это много

При стоимости сервера с 2мя 2х-ядерными оптеронами в $6k? Что скажет начальник мелкой конторки, купившей себе 2(для надёжности) таких, глядя на счёт в $240k(без опций) от оракла?

>У меня как раз такой случай был на работе, когда явабыдлокодер говорил что проще выбрать несколько десятков тысяч строк и обработать их в яве чем написать запрос на 40 строчек выдающий результат в 10 строк.

Клинические случаи мы сейчас не обсуждаем. Нам даже частичный переход на Java дал ощутимый прирост в производительности и понятийности кода.

> Во первых есть такое понятие как инерция мышления.
Это в первую очередь касается жаба-программистов, которые не знают, что с базой работаю выборками а не перебором записей.
Я нигде не говорил что PL/SQL - это сладко а жаба сосет. Никак нет. Что до меня - то я считаю PL/SQL быдлоязыком (с)LOR с минимумом возможностей, который умеет очень мало. Но достаточным для того, чтобы является неплохим простым и хорошо-читаемым процедурным расширением SQL достаточным для написания в том числе и больших проектов.

Ладно, прочь в сторону лирику. Давай практику. Что навскидку радует в PL/SQL меня:
1) Автоматическое связываение переменных.
2) И самое главное - нельзя откомпилировать код если есть ссылки на несуществующие объекты: таблицы, колонки таблиц и тд и тп. То есть PL/SQL-компилер не пропустит в рантайм код с битыми объектами.

Жаба как с этими двумя пунктами?

>1) Автоматическое связываение переменных.

Для этого у Oracle для Java есть SQLJ.

>2) И самое главное - нельзя откомпилировать код если есть ссылки на несуществующие объекты: таблицы, колонки таблиц и тд и тп. То есть PL/SQL-компилер не пропустит в рантайм код с битыми объектами.

С этим конечно хужее, но вопрос решаем, если используешь родной Oracle JDeveloper и SQLJ.

Для меня признак использования Java или PLSQL примерно следующий: если при реализации определенной задачи мне хочется создать plsql пакет, то это первый признак того, что нужно использовать Java и наоборот если при реализации задачи мне становиться лень писать Java класс, то для меня это первый признак использовать plsql. Кстати интеграция по вызовам между plsql и java у Оракла замечательная, поэтому код у нас получается несколько разношерстный... :-) но пока это не напрягает...

Sun-ch, на Oracle как правило зарабатывают, причем столько, что эти твои цены можно даже не брать в расчет.

Кстати качество кода у оракла отвратительное. Это подтвердит любой кто хоть однажды этот оракл хотя бы ставил. Оратор тут один предлагал деб пакет из рпм-ки собрать =) Ню-ню. Оракловцы скомпилили допустим 8.7.1 оракл так весело, что для того чтобы его поставить надо тащить на машину libc-compat дремучей версии, левую жаба машину, похимичить с LD_ASSUME_KERNEL, потом похимичить с подменой части жаба машины, и запустить инсталлятор. Потом игнорить ошибки инсталлятора, ни в коем случае не создавать базу, хоть он и предлагает, потом одевать патчсет который весит 180 мегабайт, потом поправить пару скриптов, и потом слинковать все врукопашную... И это ШТАТНАЯ установка на redhat 7.3. Оракловые DBA бабки рубят уже только на том что они этим тайным знанием воадеют. На большинство даже redhat based дистрибутивов оракл не становится вообще ни под каким соусом, волшебно скомпилен и слинкован потому-что. Приходится переходники под библиотеки писать и через LD_PRELOAD скармливать ему... После всего этого мне страшно представить как оно внутри все написано и сделано, и каким волшебством все более-менее отлажено что не валится постоянно (на удивление)...

8.1.7 оракл блин. Очепяталсо =(

> У меня знакомый - директор домашней сети - он так и сказал - что он планирует покупку standart edition на два процессора - и что это его ни много ни мало не напряжёт....

Это уже не домашняя сеть, ИМХО ;)

>И это ШТАТНАЯ установка на redhat 7.3
чудо, десктопные оси никогда не сертифицировались ораклом, поэтому сначала думать нада куда ставишь, ты б еще на дос попытался бы поставить и потребовать супорт. у редхат ТОЛЬКО RHEL сертифицирован.

>Кстати качество кода у оракла отвратительное. Это подтвердит любой кто хоть однажды этот оракл хотя бы ставил. Оратор тут один предлагал деб пакет из рпм-ки собрать =) Ню-ню. Оракловцы скомпилили допустим 8.7.1 оракл так весело, что для того чтобы его поставить надо тащить на машину libc-compat дремучей версии, левую жаба машину, похимичить с LD_ASSUME_KERNEL, потом похимичить с подменой части жаба машины, и запустить инсталлятор. Потом игнорить ошибки инсталлятора, ни в коем случае не создавать базу, хоть он и предлагает, потом одевать патчсет который весит 180 мегабайт, потом поправить пару скриптов, и потом слинковать все врукопашную... И это ШТАТНАЯ установка на redhat 7.3. Оракловые DBA бабки рубят уже только на том что они этим тайным знанием воадеют. На большинство даже redhat based дистрибутивов оракл не становится вообще ни под каким соусом, волшебно скомпилен и слинкован потому-что. Приходится переходники под библиотеки писать и через LD_PRELOAD скармливать ему... После всего этого мне страшно представить как оно внутри все написано и сделано, и каким волшебством все более-менее отлажено что не валится постоянно (на удивление)...

Согласен на все 100%. Хотя на солярку и на вынь никаких бубнов никогда не требовалось. Это все от лукавости линуха, имхо.

Начиная с 9.2 стало уже получше. Но инсталяция оракла, даже 7-ки, даже на практически родную SCO OpenServer очень нетривиальное занятие. Не всякая версия семёрки встанет на не всякий OpenServer. В общем, вопрос установки Oracle никогда не был без подводных камней. Зато после установки он работает. Только патчи надо вовремя накатывать... :) И, да, ORA-600 (что-то упало по SIGSEGV) меня что-то задолбали в 10.2.0.1, жду 10.2.0.2.

Как всё запущенно ... У реальных пацанов - создаешь текстовый файлик с описание структуры таблицы (очень и очень простой формат) и тебе генерится java класс для прозрачной работы с этой таблицей и другими таблицами завязанными на эту. sql запросы тоже объектами пишешь - получаешь кайф абсолютно прозрачные запросы (в текстовом виде представимых на 5-6 экранов), код не компиляеца, если чего-то не хватает. В общем, pl/sql это тока для очень сложных триггеров. Работает быстро, если ахинеей не страдать. Но как я погляжу куча людей ещё живёт в прошлом веке.

> У реальных пацанов - создаешь текстовый файлик с описание структуры таблицы (очень и очень простой формат) и тебе генерится java класс для прозрачной работы с этой таблицей и другими таблицами завязанными на эту

Ничего не понятно. Или примеры в студию.

>Кстати качество кода у оракла отвратительное.

Ну реальные пацаны, распаковывают оракл из архива правят пару текстовых файлов запускают ./sql_create.sh и через 30 минут имеют рабочую базу. устанавливали 9.0 и 9.2 на сусях с 8.2 до 10.0, редхатах, демьянах и на санах (тока архив брали другой). Инсталяторы имно нужны для нелюдей :).

Конечно не понятно для людей из прошлого веку :D :D :D. Некоторое подобие реализации объектной б.д. Для нормальной работы с одними и теми же таблицами с разных языков (с++ & java) и поддержкой разных баз данных (оракл & постгрескл).

По поводу Java в хранимых процедурах. Я бы сказал, что это имеет очень ограниченный смысл, поскольку это означает, что прямо в сервере мы реализовываем бизнес-логику, когда может оказаться лучше её вынести на отдельный сервер. В одном проекте, который разрабатывался несколько лет, когда оракл был ещё версии 7.1.6, потом он стал 7.3.4, потом 8.0.5, потом 8.1.7, потом... В общем, разрабатывался долго, с кучей кода на pl/sql со времён 7.1.6, но и не слабым количеством кода на апликешене. Так вот, когда разнесли наконец оракл отдельно, апликейшен (многопользовательский) отдельно, пользователи возрадовались жутко, что у них перестало тормозить. А апликешен поставили на всего-то dual Pentium-166/128Mb RAM. И тянул он, бедняга, 60 человек в онлайне.

Это я всё к чему. К тому, что много логики внутри сервера БД может оказаться вредно, её потом не выковырять оттуда, не вынести на другой сервер, не облегчить жизнь БД. А если логики в сервере делать только то, что принадлежит стороне сервера БД, то там будет >80% кода на чистом SQL, а значит и преимуществ скорости у Java практически не будет, всё будет упираться в сервер БД. Отсюда мораль: Том Кайл не дурак, не ретроград, не ламер, и не закостенел в мышлении, он просто оптимист -- он про нас хорошо думает, что мы не будем реализацию application server запихивать внутрь БД. Видимо, про некоторых он ошибался...

> Некоторое подобие реализации объектной б.д.

Все, дальше можешь не продолжать...

>Все, дальше можешь не продолжать...

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

Я ставил Oracle на очень разные Юниксы и очень разные архитектуры. Проблемы были только с Линуксом.

"Первая доза героина бесплатно !" (c)

>И это ШТАТНАЯ установка на redhat 7.3

Анонимус, это проблемы шапки, а не оракла. На Debian никогда не требовалось ставить ни libc-compat, ни писать LD_ASSUME_KERNEL. Так что засунь свою шапку туда, откуда достал, и больше не вытаскивай - засмеют.

Имхо не понятно что тут народ хочет от установки оракле на линукс. Народ вынте свои головы из ... серьёзно ! Оракл 8.1.* вышел когда был сузе 8.0 ... на неё он ставится без какихлибо бубнов. Потом сусе поменяли glibc на более продвинутую версию ... не совместимой со старой : нужны были бубны - как примерно сервис паки для винды. С ред-хетом думаю были теже проблемы. Сейчас есть у меня сусе 10 и оракл 10.1 и 10.2 обое ставятся без необходимых старых библиотек. Просто посмотрите сами Линух развивается быстрее чем выходят новые версии оракле(не пач-сеты). Так что сами виноваты что ставите SQL2000 на WINDOWS NT .... патчить однако нужно.

ЗЫ Ставил оракле 10.1 и 10.2 на сусе 10 ... так что ? "сусе 10" НЕ СЕРТИФИЦИРОВАНА под оракл ... потому нужно указать "игноре-ос" ! А Вы Чего Хотели ?

> Оракловые DBA бабки рубят уже только на том что они этим тайным знанием воадеют

Вообще-то обязанность владеть этими знаниями (про LD_*** и библиотеки и стабы) - это обязанность линуксовых сисадминов. no-dashi, самостоятельно и поставивший Oracle 8.1.6 на FC4 :-)

>>Для организации (не для частного лица) - $50k, да даже $100k - это вполне нормальные расходы.

>Да саныч просто в нормальных то организациях и не рабатывал! У нас вот уборщица столько в месяц получает не считая премий, всяких там бонусов и иншуэренсов.

уборщица получает $100k в месяц?

это ж как вы там гадите :))) а главное чем? ;)

>no-dashi, самостоятельно и поставивший Oracle 8.1.6 на FC4 :-)

браво! :))) осталось самостоятельно поставить на FC5 и можно смело заносить в анналы истории как самого крутого "поставлялщика" :)))

Гы, самое смешное, что в ХЕ поддержка java in BD, SQLJ, java in stored proc. просто выключена. Хоть бы посмотрели что идет в поставке. Только поддержка jdbc & .Net in DB gor Win32 ver.

Нука, крутые.. расскажите - у многих есть базы больше чем 4gb ? :) А то вопить что мало все горазды !

> расскажите - у многих есть базы больше чем 4gb ?

Думаю, что найдутся :)

Может кто-нибудь коротко описать его преимущества перед постгресом? RAW-разделы? работа на кластерах? Скорость? ...

За исключением ограничений лицензии - все.

>Может кто-нибудь коротко описать его преимущества перед постгресом? RAW-разделы? работа на кластерах? Скорость? ...

ну если очень коротенько PL/SQL. точка. :)

ЗЫ. ну и всякая мелочь типа SQL (аналитические функции/model clause), отслеживания зависимостей, пакеты, тригеры (before/after/instead), materialized view, нормальные права, ооп-фичи, утилиты (DBMS_*, UTL_*) и прочая, и прочая ...

>Нука, крутые.. расскажите - у многих есть базы больше чем 4gb ? :) А то вопить что мало все горазды !

12G

:)

>Нука, крутые.. расскажите - у многих есть базы больше чем 4gb ? :) А то вопить что мало все горазды !

165Gb

:-)

Всё-таки, маловато 4 Гб. И 1 проца тоже маловато.

> Не зря же JPL перешел на MySQL. Проперитарщина сливает в enterpriZe > по полной. Что "оракул", что "дибил-2".

> http://www.mysql.com/customers/

> И далеко не маленькие фирмы в списке.

> PS. Была инфа, о том, что Оракул собирается "поглотить" МуSQL и > зарабатывать только на поддержке и консультациях. Или ораклы > эвтанизируют.:)

Надо различать, мне кажется, задачи, которые критичны для бизнеса от задач, которые для него не критичны. Моё мнение таково, что для критичных для бизнеса задач использовать MySQL могут только долб...бы безмозглые в силу многих обстоятельств (удобство бекапа/восстановления, развитость SQL и т.д.). Да, много крупных контор используют MySQL. Но надо же знать в каких именно приложениях. Почти на 100 процентов уверен, что это какие-то очень несложные по своей структуре базы данных для очень несложных приложений (ну типа форума там или еще чего-то подобного). Так что слив энтерпрайза майсклю происходит, конечно, но в каких-то уж очень простеньких задачках, там где монстра типа Оракла ставить экономически нецелесообразно.