Размисли за великия “Оракъл”
Сигурно всеки, който знае какво е база данни е чувал за всемогъщия “Оракъл”, който едва ли не е най-добрият софтуерен продукт за всички времена. Във втори курс ми промиваха мозъка с тази база, докато на практика ми показваха работа със сървъра на М$. И двете не ми харесаха, а лекторът още по-малко – не знаеше какво е софтуер с отворен код, каза че не иска и да знае когато някой от колегите започна да му обяснява… Това беше последната лекция по този предмет, която посетих – човек, който не иска да се научи не заслужава уважние…
В крайна сметка имам 3 по бази данни – заслужавах за 4, но ми писаха по-ниската оценка, защото не съм посещавал лекциите…
Както и да е, последните 7 работни дни с колегата работим по импортиране и експортиране на данни от 2 приложения, които не могат да изполват мрежа, за да си комуникират и се налага това да става чрез човек с флашка. Та тези файлове се генерират и след това се записват в базата като blob. Отне ми няколко часа и обяснение пред трима души, но накрая ги убедих, че моето решение е добро (имах опит с него, а при другото навлизах в мътни води)… Логиката и екшъните за функционалността бяха написани сравнително бързо, записването в базата нямаше никакви проблеми и аз бях доволен…
Малко по-късно беше готова и частта с архива, която трябваше да даде произволен стар файл (в случай, че човекът с флашката загуби файла) от базата. Опитах да сваля файла – получих 86 байта глупости, имащи много бегла прилика с XML-а ми. Реших, че това е някой от по-старите записи, които ръчно бях набил в базата, но не – всички файлове, които тествах бяха точно 86 байта – доста “кръгло” число, “делящо” се на 8…
При колегата с външното приложение нещата сработиха от раз. Базите бяха на един сървър, мапингите и моделите – подобни, но той получаваше каквото трябва, а аз 86 байта…
Ръководителят на екипа ми сипа за кофти решението ми и ми каза да го направя с блоб. Казах му, че няма да стане нищо, но все пак пробвах – не се оправи проблема – 86 байта…
Тествах какво ми връща базата на заявката – естествено интелигентният оракъл клиент Sql Developer реши да се направи и да ми покаже (BLOB) вместо байтовете. След консултация с базаджии се оказа, че базата е ок – връща си каквото трябва, а моят клиент е виновен, че ми показва глупости вместо байтовете ми…
Търсих какво ли не решение в кода – пробвах настройки на библиотеките, но не помогна нищо…
Добре, какво може да е толкова различно спрямо външното приложение, което работи на tomcat и се разработва под еклипс, сравнено с това, което пиша аз, разработвано на Jdeveloper (оракълска среда) и вграденият сървър(пак на оракъл)?
Оказа се драйверът за базата. Като му дадох “вграденият” в моя Jdeveloper драйвер, приложението на колегата се счупи също. Поне бяхме открили причината…
Между другото, средата за разработка не е много стара (вграденият драйвер се казва ojdbc14.jar, а на колегата библиотеката е ojdbc14_g.jar).
Добре, взех неговия драйвер при мен – сложих го навсякъде в проекта, дадох му да се експортира – 86 байта…
Намерих го къде е, презаписах файла – 86 байта…
Изрових настройките на сървъра, забих ръчно библиотеката там и той гръмна – имало два пъти един и същи клас в пътя и моят ще бъде игнориран…
Къде мислите, че е драйверът на сървъра – в един от архивите му. Но този, който е 24 МБ…
Псувайки майкрософтските изпълнения на “оракъл” се опитах да намеря нормален сървър, да видя толкова ли са зле, но не успях. Показах на ръководителя на екипа си къде е проблема, казах му че се чупи по същия начин и външното приложение, като се ползва библиотеката, в която е драйвера от jdeveloper, а с другия драйвер всичко е точно там. Той се мъчи, мъчи, уж го оправяше няколко пъти, но все още проблемът с този сървър не е разрешен…
Кога “Оракъл” ще се научат да пишат свестни драйвери? Преди няма и 6 месеца имах проблем с друга база – трябваше да тестваме едно приложение с “Оракъл”, защото там имало най-хубавите инструменти за намиране на проблеми… Отне ми 1.5 дни да подкарам приложението на “най-великата” база, като тогава трябваше да пренапиша заявки, имена на таблици, редици и тн., защото защо да няма ограничение 15 символа на редици и май 31 на колони… Проблемът с базата отново беше драйверът им – отново взет от самите “Оракъл”…
Как може да напишеш драйвер, който да вградиш в сървъра си, а той да не работи като хората….
В случай, че се чудите, тези 86 байта се водят указател към началото на поток (или поне така пише в интернет), само дето от този поток не успях да взема нищо, дори иползвайки “оракулската” имплементация на Блоб класа. Даже с нея получавах 86 байта, които явно трябваше да са ми достатъчни…
4 Replies to "Размисли за великия “Оракъл”"
Тиндор on November 17, 2008
Сега ако ми кажеш и как да работя с Hibernate и да го накарам той автоматично да ми мапва блобовете към байтове (работещо решение, не просто решение), цена няма да имаш.
Естествено всяко решение да ползвам “Оракъл”-специфични класове отпада – приложението трябва да може да работи с всяка база (“Informix” е абсолютният минимум).
Иначе като са толкова велики “Оракъл” защо получавам очакванеото от мен поведение чрез смяна на драйвера (естествено и двете версии са техни).
Някой си on November 4, 2009
И така, човека ти показа че не е Оракъл проблема а задкормилното устройство. Сега очакваме вместо “сега ако и ми кажеш…”, да кажеш извинете, проблема е в мен! Аман от второкурсници които знаят всичко.
Лекции на Оракъл и на МС ми не ми харесаха и двете! Ми интересно що ли?
Тиндор on November 4, 2009
Не смятам да се извинявам, най-малкото защото проблемът не е в мен. Последно като проверих не работех в “Оракъл”, та не съм писал калпави драйвери. Скоро друг колега имаше подобен пробем и пак се реши със смяна на драйвери, но това е друга тема.
Що се отнася до мнението на Алекс Станев, то съм му благодарен за всичката информация, която е дал, но просто тогава не ми вършеше работа. Размерът на файловете ми беше ограничен до под 100кб. на сървър, на който разполагам с гигабайти и съм сигурен, че файловете се теглят само от един човек в даден момент…
Що се отнася до личната нападка – отдавна не съм второкурсник, но все така не съм фен на “Оракъл” и М$. Varchar2 и X509Certificate2 мисля показват достатъчно “гениалната” мисъл на системните архитекти на двете компании.
Все пак не отричам, че и двете компании са големи, а всеки сериозен бизнес ползва поне “Оракъл”, които имат всякакви глезотийки, но са пълни и с техни си странности (няма еквивалент на ilike, който прави case-insensitive like в Postgresql. Начинът да се направи е с някаква променлива на сесията.)
И все пак, не разбрах едно – защо според теб не са ми харесали лекциите по бази данни и упражненията на M$ SQL Server?
Не че ценя безкрайно много мнението на анонимни хейтъри, но все пак е мнение, което бих чул.
Alex Stanev on November 17, 2008
Практиката е показала, че 2 часа (в твоя случай 1.5 дена?) експериментиране и човъркане в кода, спестяват 5 минути четене на документация рџ™‚
Oracle е доста напредничава база данни и съответно използването на пълните възможности изисква доброто й познаване. Ако се опитваш да я управляваш като всяка друга, няма да постигнеш очакваните за този скъп софтуер резултати.
Относно ограниченията – идентификаторите на обектите са до 30 знака, като използвайки двойни кавички стават и чувствителни към големи/малки букви. Ограничението за брой колони в една таблица е 1000.
Горното е вярно поне от Oracle 8i насам.
И на въпроса: това, което четеш е така нареченият LOB locator. Това е вътрешния pointer в базата към обекта. Въпросният LOB е ограничен до 4 GB (до Oracle 11g) и не е практично да се обработва на веднъж, най-малко от гледна точка на управлението на оперативната памет.
Можеш да видиш пример за боравене с LOB обекти тук:
http://www.oracle.com/technology/sample_code/tech/java/codesnippet/jdbc/clob10g/handlingclobsinoraclejdbc10g.html
За BLOB е абсолютно аналогично.