Vlákno názorů k článku
Oracle databáze: není to tak složité, jak to vypadá
od Kolemjdoucí - Instalace DB serveru, DB klienta a vytvoření první...
-
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.
ČLÁNKY DO MAILU