Názory k článku
Oracle databáze: není to tak složité, jak to vypadá
-
sfdfadsfadsf (neregistrovaný)
Cele je to o tom, co od toho chces. Ked to beries ako "nejaku SQL databazu" a nemusis si to sam instalovat, tak tam pre zaciatocnika nie je vela narocneho a da sa to povazovat za beznu SQL databazu. Pokrocile featury tam sice su, ale daju sa odignorovat.
Instalacia je trochu narocnejsia kvoli potrebnym upravam nastavenia systemu, ale tiez sa to da zvladnut, ak si clovek Googli chyby a sam hlada, preco to nejde (napr. u mna mu nestacilo miesto na jednej partitione a nedal to sam vediet - pri sledovani som na to prisiel).
-
tdvorak (neregistrovaný)
To proto, že je to enterprise :-) Taky jsem s tím válčil dlouho, nakonec zabral návod na http://meandmyubuntulinux.blogspot.co.at/2012/05/installing-oracle-11g-r2-express.html (pro mou devel mašinu, produkci si řeší hosting team). Jako bonus mám omezenou velikost paměti i uložiště pro data (11 GB maximálně). A pokaždé, když vidím další obecnou a nicneříkající ORA-XYZ, mám chuť ten klump vyhodit a nechat obyčejné PostgreSQL. Stejně nad tím běží Hibernate, který smaže výhody a nevýhody různých DB.
-
Ivan (neregistrovaný)
Delate v Jave anebo v PL/SQL? Na dekryptovani chybovych hlasek je prikaz "oerr", ten ke kodu chyby vypise dalsi informace. Pokud delate v Jave tak mate smulu. Pokud nastane chyba, tak Oracle (alespon v OCI) vrati vektor stringu s text(y). Vsechny polozky toho vektoru zobrazi napriklad sqlplus. JDBC drivery bohuzel umi zobrazit POUZE prvni polozku. Zda se, ze autori Oracle mysleli dal, nez autori tridy java.sql.SQLException.
-
Karel (neregistrovaný)
Pokud to budete instalovat stylem MySQL, tak je Oracle také pod hodinu. Ozkoušeno, XE tu instalujeme pro kdejakou kravinu (Oracle pro jeho "create database link").
Co se nepochopitelné struktury souborů týká, tak důležité je spustit ten setup.exe a pak mačkat Next. Pokud máte na mysli to, co generuje za běhu, tak to 90% lidí k ničemu nepotřebuje.
-
Lael Ophir (neregistrovaný)
S instalací Oraclu jsem nikdy neměl problém. Instalátor vypadá jako z Marsu, ale v principu funguje. Co mě naopak nepotěšilo byly nástroje pro správu. Jsou příšerné - ty javové i webové. Další problém je ta spousta věcí, které je potřeba nastavit. A dost mi neseděl query optimizer. Občas se mi stávalo, že ta samá DB s těmi samými indexy na Oraclu zpracovávala ten samý dotaz minuty, a na MS SQL to trvalo pár sekund.
Oracle je samozřejmě nejlepší DB pro Unixy. V takovém prostředí člověk v podstatě ocení i ty GUI administrační nástroje, jakkoliv mizerné jsou.
-
To, že několik dotazů je v jedné SQL db rychlejších (byť i výrazně) prakticky nic nemusí říkat o kvalitě databáze - téměř všechny dnešní SQL databáze používají planner založený na statistikách - stačí drobná odchylka v odhadu a dostanete úplně jiný plán, jehož provedení může být stejně rychlé (ale i třeba výrazně pomalejší).
Každá databáze má svoje plusy a mínusy - u MSSQL výrazně slabší implementace uložených procedur, chaotičtější funkce (i když za to může asi ještě sybase) nebo slabší design zamykaní (což je už dnes odstraněno) - page level locks X row level locks. Jinak absolutní souhlas s tím, že GUI u MS je výrazně přátelštější než v Ora. Nicméně to vychází z jiné tradice (a z jiných zákaznických požadavků) - pokud je člověk uvyklý na MS, pak chápu, že se v Unix like UI dělá špatně - navíc v sw, který je na konfiguraci a management výrazně náročnější než MSSQL (také rozsah Ora je několikanásobně větší než MSSQL).
-
Firmy, které migrují z Oracle na Postgres nemigrují kvůli komplexitě administrace, instalace - to nějak zvládly, a většinou mají tým, který se s rozsahem Oracle docela dobře vyrovná - a velké instituce mají většinou docela dobré lidi. Hlavním důvodem jsou vysoké provozní náklady (cena za support). To je asi teď největší problém Oracle, kvůli kterému ztrácí uživatele (což je asi zjevně netrápí, protože se přesouvají k hw a cloudu).
-
Lael Ophir (neregistrovaný)
Ad To, že několik dotazů je v jedné SQL db rychlejších (byť i výrazně) prakticky nic nemusí říkat o kvalitě database - souhlas, ale taková je moje zkušenost s Oracle: občas něco běželo daleko pomaleji než na MS SQL Serveru. Opačně se mi to nestalo ani jednou. Je možné že jsem měl prostě smůlu na "nevhodné" dotazy.
Ad u MSSQL výrazně slabší implementace uložených procedur - dnes je můžete psát v .NETu nebo i C++. Ale větší databáze se stejně doporučuje implementovat jako CRUD.
Ad chaotičtější funkce (i když za to může asi ještě sybase) - funkce mi přišly v pohodě, naopak Oracle PL/SQL je dost peklo. Ale to může být o tom na co je člověk zvyklý.
Ad slabší design zamykaní; page level locks X row level locks - row level locks má snad 17+ let :). Nemáte na mysli Multi-Version Concurrency Control? -
Nazory co psat v ulozenych procedurach se dost rozchazeji - od nic, po CRUD az po temer vsechno - a mam pocit, ze to castecne koreluje se silou integrovaneho jazyka. Silne ovsem zalezi na tradici a kvalite developeru. Procedury v C++ pro MSSQL jsem psal uz pred 15 roky - a neni to, nic, co bych si chtel zopakovat - .NET procedury jsou uz user friendly, ale bez integrace SQL je to porad neco uplne jineho nez psani procedur v PL/SQL. Napr. design funkce CONVERT http://www.w3schools.com/sql/func_convert.asp je vyslovene povedena zalezitost. Ono to pomalu 13-14 let bude, co jsem s MSSQL delal naposledy :) - MVCC dostalo MSSQL jako jedna z poslednich db.
-
Cohen (neregistrovaný)
No vidíte a já mám (jako primárně MSSQL vývojář) s výkonem přesně opačnou zkušenost. Dost často se setkávám se situací, kdy MSSQL prostě dotaz naplánuje tak otřesně, že trvá i 10 sekund a když ho následně rozložím do temp tabulek a udělám join nad nimi, dostanu se klidně i na 50ms. Naopak výkon Oracle mě většinou dost mile překvapil.
Nicméně nedělám z toho žádné zvláštní závěry. Srovnávat výkon db strojů je nesmírně ošemetná záležitost, většinou jste svázán návyky z jedné databáze a urputně se snažíte použít stejné postupy i na konkurenční platformě, takže to zákonitě musí skřípat. A je to hodně o "náhodě", stačí se podívat, co si myslí uživatelé o novém cardinality estimatoru MSSQL 2014. Někdo je nadšený, někdo hlásí, že je to horší než kdy dříve.
Co se týče GUI, tak třeba takový Oracle SQL Developer 3.2, to bylo peklo, několikrát mě kvůli němu málem odvezla sanitka. Zamrzávání, pády, kradení focusu. Aktuální verze je tedy o dost lepší, rozhodně bych jí neoznačil apriori za příšernou.
A když jsme u toho, tak najít něco mezi 20 otevřenými dokumenty v SSMS, to je práce pro vraha.
-
Honza Lan (neregistrovaný)
Prošel jsem si program školení a upřímně vůbec mi to nesedí s délkou školení. Pokud se opravdu bude školit všechno co je vyjmenováno, pak to je na úrovni toho, že se posluchač dozví co ta konkrétní věc zhruba je. Rozhodně se nedá stihnout praktická konfigurace.
Spíš bych to nazval jako úvod do prostředí Oracle.
-
Ten systém navrhoval mimozemšťan, chcete naprosto blbost a strávíte nad tím hodiny.
Naprosto neintuitivní, záměrně brzdící produktivitu. To co v jakékoliv jiné databázi je hotové okamžitě, je tady a to zdůrazňuju záměrně debilně udělaný, aby se na tom dalo pořádně rejžovat.
Přitom je to jen databáze, takže vlastně skoro nic. Naštěstí v dnešní době integračních platforem ESB, různých API apod. už je téměř jedno v čem jsou data uložena.Napíše vám to některý z tisíců chybových kódů a problém je samozřejmě úplně někde jinde.
Můžete ale zákazníka pořádně oškubat a tvářit se tajuplně, že ta super enterprise technologie prostě potřebuje drahej servis :-) na většinu věcí by kolikrát stačila i SQLite.
Ale tak před mnoha a mnoha lety to asi bylo zajímavé. -
asd (neregistrovaný)
Konkurence v podobe MySQL, nebo PostresSQL? Nemyslim, ze cilovy zakaznik je stejny.
Kdyz uz srovnavat vykon Oracle, tak s DB2 (asi nejblizsi podobny produkt), Informixem nebo jeste rekneme MS SQLServerem (pokud bereme enterprise segment).
A tam vytezi ten system jehoz producent si tu analyzu zaplatil. :-) -
Chtěl bych se zeptat, jestli součástí školení bude i několikadenní přednáška o tom, jak se v produktech Oracle nesmí hledat chyby a nedej bože dělal reverzní inženýring kódu. Nazval bych tuto nosnou část školení například: "No, You Really Can't". Součástí by měl být také brainwashing na téma, jak bychom měli slepě důvěřovat svému dodavateli.
-
To ti vysvětlím za 5 minut a zadarmo:
1. Nesnažit se hledat chybu pomocí logiky
2. Zkoušet náhodně měnit různé kusy kódu a nastavení dokud se to nerozjede
Toto je standardní způsob řešení chyb v oraclePříklad:
SELECT a.* FROM Account AS a WHERE a.UserName != 'krtek'
Chyba v dotazu: ORA-00933: SQL command not properly endedZ chybové hlášky je naprosto jasné že mezi "Account" a "a" nesmí být "AS"
-
Ivan (neregistrovaný)
V tomhle pripade na tom neni zadna databaze lip. SQL ma hodne divokou gramatiku a bez backtrackingu se proste parsovat neda. A kdyz se parser nekolikrat rozejde dopredu a pak se zase vrati, aby vyzkousel vsechny vetve, tak proste nemuze rict kde presne je chyba (u kazde vetve skoncilo parsovani nekde jinde).
Navic Oracle uz fanaticky dodrzuje zpetnou kompatibilitu. uz minimalne 20 let nepribylo v Oracle zadne rezervovane slovo - tzn. takove ktere nejde pouzit pro nazev tabulky. Pridavaji se pouze klicova slova - tzn. takova, ktera mohou mit zvlastni vyznam, ale zaroven je muzete pouzit pro jmena objektu. Dodnes muzete pojmenovat tabulky jmeny jako A (soucast IS A SET operatoru), AS, JOIN anebo COMMIT.
Cim je gramatika slozitejsi, a Oracle SQL je opravdu hodne slozite, tim hure se hleda kde vlastne presne doslo k chybe parsovani. Navic si myslim, ze nejakej rozumejsi tool Toad/SQLDeveloper/Tora by vam aleson nejaky offset chyby vratil. Pouziva se k tomu dbms_sql.parse.
PS: kdyz vidim jaky zvrhlosti provadi MySQL se svym klonem SQL, tak na tom budou za chvili jeste hur.
PPS: pokud jde o DB2, tak se mi vzdy vybavi tohle: http://www.hovnokod.cz/763
ČLÁNKY DO MAILU