Databáze proti databázi – kdo vítězí?

Diskuze čtenářů k článku

Lukoko  |  26. 06. 2006 01:05  | 

To je vsechno moc pekne, ale co vykon dane databaze, jestli bude mit dany databazovi stroj pro danou aplikaci mnohem vyssi vykon, tak proc nezaplatit o neco vic? Vyplati se vic o par procent levnejsich serveru, nebo min mnohem vykonejsich?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Karel Kahovec, Karel Kahovec  |  26. 06. 2006 06:31  | 

Inu, ve výkonu vede MS SQL taky. A navíc je levnější.

Souhlasím  |  Nesouhlasím  |  Odpovědět
sr  |  26. 06. 2006 09:47  | 

což samozřejmě není pravda, protože rekord v databázových aplikacích nedrží nikdo jiný než Oracle
kdyby tě to zajímalo, tak stačí trochu Googlovat
http://www.oracle.com/global/cz/corporate/pressroom/2006/060209_tpc.html

Souhlasím  |  Nesouhlasím  |  Odpovědět
Mraca  |  26. 06. 2006 10:15  | 

A jako zdroj jsi zvolil pressrelease oracle....

Souhlasím  |  Nesouhlasím  |  Odpovědět
sr  |  26. 06. 2006 10:35  | 

samozřejmě, tak jako tady byl zvolen MS test
původně jsem tu zprávu viděl na www.lbw.cz, ale jednodušší bylo najít ji na stránkách Oracle. To ale na věci nic nemění - rekord patří Oracle.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vetrak  |  26. 06. 2006 18:28  | 

Pozri si benchmarky kdekolvek na nete, zistis, ze MS SQL vyrazne zaostava, dokonca je az treti za Oracle a MySQL/MaxDB. Samozrejme, zalezi, co testujes. Cakalo sa, ze MS SQL 2005 prinesie narast vykonu oproti predoslym verziam, ale nie je to take ruzove.

Souhlasím  |  Nesouhlasím  |  Odpovědět
oplo  |  26. 06. 2006 11:30  | 

To je blabol! MS SQL Server je ta nejchciplejsi databaze co znam. Kecam a opravuji, nejchciplejsi je MS Excel s 100MB souborem. MSSQL je tesne pred nim.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ja  |  26. 06. 2006 12:04  | 

To nebude chyba MSSQL, spis vase ...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Fireman  |  26. 06. 2006 16:59  | 

LOL jak muze nekdo mluvit o databazovych serverech a radit do nich MS Excel?

A nejpomalejsim autem je ponorka ze?

Souhlasím  |  Nesouhlasím  |  Odpovědět
HáRoš  |  28. 06. 2006 08:57  | 

Ponorku samozřejmě nelze řadit mezi automobily, protože svým osvětlením nesplňuje vyhlášku o provozu na pozemních komunikacích. Samozřejmě, za určitých podmínek, lze ponorku použít ke stejnému účelu jako automobil - tzn. např. k přepravě nákladu nebo osob. O vhodnosti takového řešení si musí úsudek řidič ponorky vytvořit sám.

A s Excelem to je stejné

Souhlasím  |  Nesouhlasím  |  Odpovědět
Izak  |  26. 06. 2006 16:35  | 

Jo i na Unixu ci Linuxu, takovy AIX s CPU Power neporazi M$ SQL jeste dlouho.
On totiz nay Sybase nebezel na windows kdovijak rychle

Souhlasím  |  Nesouhlasím  |  Odpovědět
abcdef  |  26. 06. 2006 19:53  | 

A proto Sybase s oblibou nasazujeme na linux

a propo... mssql nesleduji (nejde nasadit na linux:) tak se zeptam: uz umi zalohovat online?

Souhlasím  |  Nesouhlasím  |  Odpovědět
RADl0PASlV  |  26. 06. 2006 20:12  | 

Samozřejmě, že umí. Minimálně od verze 7.0 (z roku 1998, dřívější už nepamatuju). A jestlipak vaše oblíbená databáze umí online obnovu databáze? SQL Server 2005 ano.

Souhlasím  |  Nesouhlasím  |  Odpovědět
abcdef  |  26. 06. 2006 20:21  | 

hmmmm, to jsem nezjišťoval, Sybase na linuxu ztrácí data jen když odejde disk, to pak jaksi není online kam nahrát

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vasik  |  27. 06. 2006 21:52  | 

Online obnovu databáze??!! Co je to za žvást!! To je naprostý protimluv. Online znamená za běhu aplikace používající databází. Jak by asi aplikace mohla nad databází pracovat, když právě probíhá obnova, respektive když ještě nejsou všechna data dostupná. I kdyby to nějaká databáze uměla, který šílený administrátor by tohle dělal!!
Jooo, jestli mluvíš o pouhém recovery po pádu instence, to je hraní na dětském písečku, to dneska každá databáze udělá okamžitě automaticky. Obnova znamená, že jsi ztratil datafile s tabulkami a děláš restore z backupu datafile a redo logů. Při něčem takovém by pouštěl aplikaci jen šílenec. Možná kdyby jsi měl více aplikací v databázi a každá měla svoje datafile, pak se dá uvažovat o postupné obnově a zdvihání jedné po druhé, tedy jakési "pseudo" online, ale stejně bych do toho nešel.
 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Izak  |  27. 06. 2006 00:02  | 

To uz umi dloho, jenze M$ SQL admini jsou trotli a mysli si, ze journal je pro novinare .... a protoze vyvojari to vypinaji, tak uz to admin nech tak (dostane server s odladenou aplikaci)

Jinak uz ma windows jounal FS .. Neee? Tak s tou hracklu jdete nekam .... jo jeste si to dejte na windows 2000 dinamicke disky to je pak tabulka v pr....

Souhlasím  |  Nesouhlasím  |  Odpovědět
Izak  |  26. 06. 2006 23:57  | 

Jo samozrejme jsem to myslel tak, ze Oracle je na Linux/Unix vikonnejsi

Souhlasím  |  Nesouhlasím  |  Odpovědět
PSenderoz  |  26. 06. 2006 21:00  | 

MS SQL je výkonnější než Oracle? Co to zde blábolíte? Můžete takovou kravinu podložit? Nemůžete! Protože v licenci formy Oracle je zakotveno, že není dovoleno publikovat výsledky žádných výkonostních testů. Je to proto, aby podobní kvákalové jakoste vy nemohli provádět ubohé "polotesty", ve kterých by vyhrával Microsoft...

Takže je to jen blábol někoho, kdo se ani nezačetl do dokumentace Oraclu...

Souhlasím  |  Nesouhlasím  |  Odpovědět
PakoMako  |  26. 06. 2006 01:36  | 

Muhehe, tak to je tedy test jak moje stehno.
1. Dva stejni vyvojari v ruznych platformach. Muhehehehe hehe hehe he, jak to poznaji?
2. Srovanavat cas dvou lidi nad stejnym ukolem? To ma byt reprezentativni vzorek? A co kdyz se jeden z nich blbe vyspal zrovna v den testu?
3. Srovnavat nejaky priblbly report? Podle jine statistiky mohu prohlasit, ze reporty tvori 5% veskere vyvojarske prace.
Takze podtrzeno secteno, v pripade porovnani vyvojaru jde o naprostou hovadinu
a jen tak mimochodem, nedelam sni v MS SQL (diky bohu) ani v Oracle.

Souhlasím  |  Nesouhlasím  |  Odpovědět
adam  |  26. 06. 2006 02:29  | 

Presne, tech vyvojaru melo byt 10 na kazde strane a kazdy resit ukol samostatne. Take tech ukolu melo byt vic. Co ja znam microsofti nastroje, tak na demoverze, koukejte jak snadno jde udela tohle, jsou orientovany, ale v praxi to moc vyuzitelny neni, zvlast kdyz potrebuje neco trochu jineho, a to je vzdy. U kazdeho projektu jsou zvlastni pozadavky, kdyby nebyly, pouzilo by se krabicove reseni, ne vyvoj na zakazku.

Souhlasím  |  Nesouhlasím  |  Odpovědět
TNT  |  26. 06. 2006 11:30  | 

Pravda je, ze tech vyvoaru melo byt vice a meli by mit za ukol kompletni vytvoreni DB schematu, spolecne s mnozinou views, ulozenych procedur a funkci...
 
Tam by totiz Oracle dostal na prdel uplne ... Kdoi zna oba Db systemy a ve sve profesi musi s obema pracovat, vylozene nesnasi Oracle a pri vysloveni tohoto slova mu naskakuji pupinky
 
Par malych prikladu:
 
1) Specifikace SQL - Oracle stale pouziva 92, takze zpatky na stromy, napr. realizace INNER JOIN (tedy vnitrniho spojeni)
 
SELECT * FROM a JOIN b ON ... vs SELECT * FROM a, b WHERE
 
2) OUTER JOIN na Oracle vice, nez dvou tabulek NELZE. "ORA-ERR Table may by outerjoined at most at one table", takze se dela JOIN na SELECT ze SELECTU ... Krasny maras pri vice tabulkach ...
 
3) rozdilnost PL pro analyzu dotazu, napr. v zabe, vs. PL zkompilovatelneho na Oracle DB. Vymyslite-li si neco, co vam v zabe slape a chcete z toho udelat storku - SSSMMMMUUULLLAAA, nemzusi slapat
 
4) Oracle NULL vs. empty string - nevnima rozdil, takze zapis NVL(null,'') nema smysl resit...
 
5) Oracle procedury a PL obecne nedokaze vracet result-set jako standardni SQL dotaz. Resit se da pouze refCursorem - o nicem! Znamena to tedy, ze na Oracle nenapisete storku jako:
CREATE PROCEDURE sp_LIST
 
@parametr
 
AS
 
SELECT * FROM tabulka WHERE parametr=@parametr
 
 
atd atd atd... napr. pracovni a temporary tabulky (podotykam, ze toto nejsou identicke zalezitosti) ...mohl bych to tu psat cely den... Kdo vi, ten vi... Ostatni jen "sektarsky" krici fraze, ktere jiz davno nejsou pravdive...
 
Zaver, clanek je PRAVDIVY, a z hlediska smiru s Oracle byly testy omezeny jen na oblast, kde by rozdily nebyly tak markantni ...¨
 
Have a nicde day
 
PS: Co se tyka vykonu,  vzhledem ke slozitosti i banalnich reseni (prevazne kvuli specifikaci 92 a take YntelYgencY PL) je vykon na Oracle jedno)znacne zpochybnitelny. Dejte si nekdy tu praci a porovnejte v realu ...
 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jaja  |  26. 06. 2006 12:36  | 

Vrat se ze stromu a zkus si obcas neco precist v dokumentaci. Body 1 a 2 plati tak pro verzi 8 (ktera uz dnes ani neni podporovana) a dnes uz mame 10 . Vyrostl jsi na MS SQL a ted se nechces ucit jak se to dela Oracle (jak treba naznacuje poznamka o temporary tabulkach) . Kdo si mysli ze stejne tak ma pupinky.

Jedine za co muzeme podekovat MSSQL a Microsoftu je silny tlak na licencni politiku na vicejaderne procesory. Na niagare mame 8 jader za cenu 2 CPU no neni to parada?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Kodl  |  26. 06. 2006 15:10  | 

2TNT: Normálně moc příspěvky nepíšu, ale tyhle tvé sebevědomé, znalostmi nepodložené výkřiky mě uvedly do varu .
K tvým příkladům:
1 a 2) Oracle začal podporovat syntaxi tzv. OUTER joins a INNER joins jako první produkční (komerčně prodávaný) databázový systém. Bylo to ještě předtím, než zasedla komise ANSI a mohla vymyslet moderní JOIN syntaxe, které tu zmiňuješ. Proto se v databázi Oracle až do verze 9.0.1 objevovala původní jejich syntaxe JOINů. Od verze 9.0.1, tedy již 6 let, fungují v Oracle obě JOIN-syntaxe. Možná by sis měl takovou věc nejdříve vyzkoušet před zařazením plamenného výkřiku do diskuze !
3) Programuji v Oracle více než deset let a na takový případ, jaký popisuješ jsem nenarazil, což však nemusí znamenat, že nemáš pravdu, jen je mi to divné. Samozřejmě, něco jiného je, pokud při přepisu SQL do PLSQL pozměníš znění původního SQL např. záměnou konstant za "bind"-proměnné. Tomu se pak samozřejmě musí optimalizátor přizpůsobit a je klidně možné, že zvolí jinou cestu pro získání téhož výsledku.
4) Máš pravdu. Na to, že je v Oracle prázdný řetězěc ('') shodný s výrazem NULL je potřeba si dávat pozor.
5) Oracle nedokáže vracet result-set z PLSQL? A co takhle pipelined functions? Klidně provedeš SELECT * FROM PLSQL_FUNC(params). Dokonce parametr takové PIPELINED PLSQL funkce nemusí být scalar type, ale zase další SQL kurzor, takže se dá udělat například velmi efektivní transformační roura ETL procesu SELECT * FROM PLSQL_FUNC1(SELECT * FROM PLSQL_FUNC2(SELECT * FROM PLSQL_FUNCn(SELECT * FROM ext_table))).
Tak jen doufám, že jsem uvedl na pravou míru kvalifikovanost tvého příspěvku. Do komentářů k porovnávání výkonnosti databází a nákladů spojených s vývojem či jejich administrací se nechci pouštět. Je mnoho možností, jak se k testu postavit a se stoprocentní jistotou již před začátkem predikovat výsledek.
Ještě poznámka k těm dočasným a pracovním tabulkám - Oracle zavedl ve verzi 10g global i session temporary tables. Snažil jsem se přijít na to, k čemu bych tak mohl tuhle fíčuru využít. Zjistil jsem, že ji nepotřebuji. Jedná se od Oraclu asi spíše o vstřícný krok příležitostným MSSQL vývojářům zvyklým na dočasné tabulky z MS SQL.

Souhlasím  |  Nesouhlasím  |  Odpovědět
TNT  |  27. 06. 2006 09:49  | 

Tak tedy
 
k bodu 1) aplikuj nize uvedeny dotaz a napis, od ktere verze to na oracle facha:
SELECT * FROM A LEFT JOIN B ON ... LEFT JOIN C ON ... Samozrejme, ze stupidni INNER JOIN Oracle umi (kdyby neumel, to by byl uplne na odstrel ...
Dale pak aplikuj do LEFT-RIGHT INNER-OUTER  JOIN ON podminku AND (... OR ... )
Pak si tady vylevej srdicko s deseti lety praxe na Oracle 8-)
 
k bodu 3) Hodne systemu, prevazne tech nejvetsich v CR bezi stale na Oracle 8, maximalne 9 ... Zkus si napsat v zabe:
SELECT (CASE WHEN ... ELSE END) jako PL script a pak toto zakomponuj do nejake stupidni storky... Kdyz ti to pojede, mas stesti a samozrejme i novejsi PL na Oracle
 
ad 5) proverim si to.
 
Apropos, neplacal jsem nesmyly, je to kazdodenni realny zapas s neprizni Oracle. Uvedom si, ze nemalo provozu neupgraduje verze Oracle jen tak, jak jsem psal, hodne (prave velkych) spolecnosti s tim ma procesni trable, takze se verze vyrazne zpozduji ... Zminovane neduhy lze ale obecne srovnavat i s MS SQL 2000, nejen 2005.
 
 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Kodl  |  27. 06. 2006 11:28  | 

TNT, sorry za ta včerejší invektiva, nechal jsem se tvým příspěvkem vydráždit  
Teď k faktům:
k bodu 1 a 2)
ANSI join-syntaxe, o kterých píšeš, funguje na všech verzích, na kterých mám momentálně možnost to vyzkoušet, tj. Oracle 9.2.0.3, 10.1.0.4, 10.2.0.2. Verzi 9.0.x teď k dispozici nemám, ale tam by měla tato syntaxe také fungovat. Vícetabulkový OUTER JOIN je pomocí této syntaxe také realizovatelný bez nutnosti vnořování SELECTů, o které jsi psal.
Nevím, co jsi myslel tím "Dale pak aplikuj do LEFT-RIGHT INNER-OUTER JOIN ON podminku AND (... OR ...)"!? Když uvedeš konkrétní příklad, otestuji jej pro tebe, chceš-li  . Zdá se, že ty asi tu možnost, ověřit si prakticky své teorie, nemáš .
k bodu 3) Tento kód jsem vyzkoušel na historické verzi 9.2.0.3 - funguje bez potíží:
CREATE
OR REPLACE FUNCTION get_salary_func(p_ename VARCHAR2) RETURN NUMBER AS
  l_sal NUMBER
;
BEGIN
  SELECT

    (CASE WHEN d.dname = 'ACCOUNTING' THEN NULL ELSE e.sal END) censored_salary
  INTO
    l_sal
  FROM

 
   emp e JOIN DEPT d ON (e.deptno = d.deptno)
  WHERE
    e.ename = p_ename
;
  RETURN l_sal
;
END;

Situaci s aktuálně používanými verzemi Oracle v různých podnicích v ČR (i v těch největších) znám dobře. Převažuje 9.2.0.x, ale mnoho podníků již upgradovalo na 10.1.0.x. Verze 10.2. se zatím nestihla rozšířit na produkční systémy. Verze nižší než 9.2 se již vyskytují výjimečně.
Správce databází v podnicích nutí k upgradování politika podpory Oracle. Například, verze 9.0.x, o které jsem psal ve svém minulém příspěvku, je již delší dobu "desupported", což znamená, že obrátíš-li se na Oracle s tím, že chceš aby ti pomohli vyřešit nějaký problém s 9.0.x , řeknou ti, ať si nejdříve zaktualizuješ databázi na některou z verzí, která je ještě podporovaná. Momentálně nejstarší podporovaná verze je 9.2, ale to platí také jen do června příštího roku.

Souhlasím  |  Nesouhlasím  |  Odpovědět
TNT  |  27. 06. 2006 12:49  | 

fpoho... beru to sportovne...
 
s temi outer joiny na vice tabulek si nejsem jisty, mi to neslape ani na vyssich verzich. Co se tyce case whenu, je to problem malinko starsi, nicmene, jiny (novejsi) priklad ted nemam. Fakt je ale ten ze se PL ve verzich pro storky a pro preklad dotazu napr. ze zaby rozchazi.
Co se tyka AND a OR, mel jsem na mysli podminku, ktera spoji tabulky i na zaklade "nebo" ... nejen "and" ... nejcasteji se jedna o marjetingove vystupy a je to jedina cesta, jak nad rozsahlymi daty obejit UNION ...
 
Asi nema cenu to vice kuchat. Obecne si myslim, ze moznosti prace s daty jsou na MS propracovanejsi dosti vyrazne... Tim ale nezpochybnuji prozatimni vedouci pozici Oracle ve svete databazi. Jsem ale presvedcen, ze by Oracle corp mela vice zamakat a zamyslet se nad sebou, jako to napr. udelal MS, zahodili vsechno, co meli a zacli znovu - od piky.
 
Vratim se jeste k pipelined functions. Neresi to ale myslim fakt, ze PL obecne nevraci result-sety, muzes si udelat select z cehokoliv, ale vzdycky musi byt INTO neco. Ulozena procedura ti jako vystup nevrati data podobne, jako klasicky SQL dotaz. Anebo se pletu?
 
tech problemu s Oracle vs MS je mnohem vice. V nektere ze starsich diskusi uz jsem je tu vypisoval. nema cenu ale porad otravovat sebe i ostatni (i tebe). Co clovek, to nazor. Posledne jsem to tu vehementne diskutoval s Jajou a dneska se do toho oprel znova (nad tebou) ...
 
Have a nice day ...

Souhlasím  |  Nesouhlasím  |  Odpovědět
jaja  |  27. 06. 2006 14:10  | 

Akorat mam pocit ze jsi pristupoval z jine firmy :) Snad jsi nedostal padaka?
Ale musis si priznat ze jsi od minule moc nezlepsil

Porad stejne narky a ignorovani nasich odpovedi. To ze se nekde jede na starsich verzi Oracle je bohuzel pravda. Duvody jsou ruzne a neochota vyvojaru testovat a prepisovat sve stare aplikace je jeden z nich.

Souhlasím  |  Nesouhlasím  |  Odpovědět
TNT  |  27. 06. 2006 14:56  | 

neboj, padaka jsem nedostal...
 
Jinak, tve odpovedi i posledne jsem cetl a reagoval na ne, paxem se myslim ale stejne nedockal odpovedi.
 
Pro vas oba, jak je to tedy s tim navracenim result-setu z ulozenych procedur? Tzn. mohu v zabe zavolat jmeno storky a vysype se mi editacni datagrid, jako po zavolani selectu?
 
 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Kodl  |  27. 06. 2006 15:45  | 

Vytvořil jsem jednoduchou ukázku pipelined function:
CREATE
OR REPLACE PACKAGE pipe_pkg IS
  TYPE emp_tab_t IS TABLE OF employees%ROWTYPE;
 
FUNCTION get_dept_employees(p_deptid IN NUMBER)
   
RETURN emp_tab_t PIPELINED;
END
pipe_pkg;
/

CREATE
OR REPLACE PACKAGE BODY pipe_pkg IS
 
FUNCTION get_dept_employees(p_deptid IN NUMBER)
   
RETURN emp_tab_t PIPELINED IS
 
BEGIN
   
FOR lc IN (SELECT * FROM EMPLOYEES e WHERE e.DEPARTMENT_ID = p_deptid) LOOP
     
PIPE ROW(lc);
   
END LOOP;
   
RETURN;
 
END;
END pipe_pkg;
/

SELECT
* FROM TABLE(pipe_pkg.get_dept_employees(60));
A to je vše přátelé!!!

Souhlasím  |  Nesouhlasím  |  Odpovědět
TNT  |  28. 06. 2006 09:05  | 

dobryyyyy.... ale to neniiiii onnnoooo ....
 
Chci neco takoveho: V T-SQL
 
CREATE PROCEDURE sp_LISTUJ
 
@p_n_X int,
@p_n_Y int,
@p_n_Z Int
 
AS
 
SELECT
*
FROM
tbl_XYZ
WHERE
X=@p_n_X AND Y=@p_n_Y AND Z=@p_n_Z
 
... a toto potom volat z nejakeho GUI, napr zaby:
 
EXEC sp_LISTUJ 1, 2, 3
 
... aby se dole vysypaly zaznamy v gridu .... toto je jednoduchy priklad, v praxi se ale vetsinou jedna o slozitejsi veci, jako napr. parametricky definovany ORDER BY, parametricky definovne filtry, tzn vsechny zaznamy anebo podle where, nejlepe bez pouiziti IF (reseni je easy), atd atd atd... Proto jsem jako jednu z mnoha veci vyzdvihniul prave tento problem ...
 
... v odlehcene forme to napr. znamena, ze vykaslu-li se na storky, ale napisu-li si nejaky parametrizovatelny SQL script, nemuze mi tento script vratit result-set, aniz bych si ty data nekam docasne neulozil, napriklad do tmp tabulky... Vzdycky musis rozlisovat PL-SQL cast a pak standardni SQL cast, kde jiz je mozne prikaz SELECT aplikovat ... To je to, co jsem mel na mysli...
 
nepopiram, ze Oracle je vyborna vykonna databaze, nicmene prace s ni je tragicka a frustrujici... Bohuzel...
 
ale jinak diky.... priznam se, ze pipelined functions jsem neznal a je to pro me vzkutku velmi prinosna informace...
 
tebe i Jaju bych nekdy rad poznal, myslim, ze bysme mohli dobre pokecat - nejen o Oracle vs. MS SQL ,,,
 
 
 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Kodl  |  28. 06. 2006 10:35  | 

Uznávám, že ten zápis z MSSQL je působivý a jednoduchý, ovšem nějak nevidím rozdíl ve výsledné funkčnosti.
"exec sp_LISTUJ 1, 2, 3" je poměrně nestandardní zápis, u kterého by člověk intuitivně nečekal, že mu vrátí result-set. Syntakticky je mi více po srsti použití toho "SELECT * FROM TABLE(function)", který jsem napsal předtím, ale to je subjektivní věc. V žábě ti ten můj zápis normálně vrátí záznamy do datagridu - v tom se to neliší od jakéhokoliv jiného SELECTu.
Jak vidíš z mého příkladu, pipelined funce lze použít pro parametrické filtrování, uniká mí ale důvod, proč nenapsat stejnou podmínku přímo do WHERE, případně, pokud je to statická podmínka, tak napsat klasické VIEW anebo, pokud je to dynamická záležitost, například podmínka závislá na přihlášeném uživateli, využít Oracle Virtual Privat Database (Oracle VPD) a Fine Grained Access Control.
Mimochodem, zmíněný FGA je výborná věc. Zní to složitě, ale přitom je to velmi jednoduché - tvá PLSQL funkce po zaregistrování vrací řetězec, který Oracle automaticky doplní do prováděného SQL příkazu do WHERE klauzule, samozřejmě v závislosti na tom, ke kterému objektu se v SQL přistupuje.
Všimni si také, že žádný příkaz IF ve funkce k filtrování nebyl potřeba. Není problém funkci použít pro parametrizovatelné ORDER BY (použije se jen ve funkci dynamický kurzor "OPEN c1 FOR 'SELECT * FROM employees ORDER BY last_name'". To mi ale připadá jako blbina, protože ORDER BY si většinou definuje koncák - tedy buď aplikace nebo přímo pisatel SQL (ORDER BY lze samozřejmě aplikovat i na vrácený result-set z pipelined funkce - "SELECT * FROM TABLE(pipe_pkg.get_dept_employees(60)) ORDER BY LAST_NAME").
Výhodou použití zápisu SELECT * FROM TABLE(function) oproti "exex proc" je možnost klidně výsledný result-set dále joinovat s dalšími tabulkami, aplikovat na něj WHERE podmínky a obecně veškerá zvěrstva, která SQL umožňuje :
SELECT

  d
.DEPARTMENT_NAME,
  e.LAST_NAME,
  e.FIRST_NAME
FROM
  TABLE(pipe_pkg.get_dept_employees(60)) e
  NATURAL JOIN DEPARTMENTS d
ORDER BY
 
e.LAST_NAME
K tomu případnému pokecu - piješ ty a Jaja pivo?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Kodl  |  28. 06. 2006 10:39  | 

Oprava - tím dynamickým kurzorem jsem samozřejmě myslel zápis "OPEN c1 FOR 'SELECT * FROM employees ORDER BY '||p_order_by;"

Souhlasím  |  Nesouhlasím  |  Odpovědět
TNT  |  28. 06. 2006 13:12  | 

jasne.... pifko mam moc rad...  kdy akde? btw, bohuzel, nejsem z PHA ...
 
Zpet k clanku... predpokladej, ze se aplikace x-krat prihlasuje stale pod stejnym userem. Nemuzes potom ohnout logiku podle usera. Jenze kazda z techto seanci chce z jednoho zdroje parametrizovana data, setrizena taky parametricky... Napr. vysledky vyhjledavani na nejakem shopu popr. nejakem person IS, pricemz pri vyhledavani si taky nadefinujes order. Skladat dynamicke SQL primo v aplikaci je docela proti srsti mi, ale to je taky otazka nazoru...  

Souhlasím  |  Nesouhlasím  |  Odpovědět
Kodl  |  28. 06. 2006 15:06  | 

Nám v Brně naštěstí Přema opravil vylágrované cajzlovské bazmek, takže škopek chlemtáme ostošest.
K tématu: uživatelská rozhraní moderních systémů (formuláře, reporty, datagridy) se stejně většinou staví jako skládačky z již připravených komponent nebo knihoven (viz TOAD), které na jedno kliknutí do záhlaví změní ORDER BY. Ovšem chápu, že nelze všude použít připravenou komponentu. V tom případě je možné použít právě třeba tu pipelined function. Za sebe bych ale raději šel cestou dynamického skládání SQL. Na výpomoc bych si vzal jednoduchou funkci (napsanou v čemkoliv a kdekoliv), která mi vrátí na základě pole s názvy sloupců tabulky, podle kterých chci řadit, řetězec, obsahující již hotovou sestavenou ORDER BY klauzuli, kterou bych pak jen připojil na konec textu SQL, který posílám databázi. Podle mě to vyjde nastejno, jestli sestavuješ parametry volání uložené procedury nebo jestli sestavíš přímo SQL text. V každém případě, v databázi Oracle máš díky pipelined functions také obě možnosti. Každý podle gusta.

Souhlasím  |  Nesouhlasím  |  Odpovědět
jaja  |  28. 06. 2006 12:17  | 

jak jsi popisoval problem s ruznym chovanim optimalizatoru u selectu v zabe a ve storce, nevypadalo nahodou podobne jako tenhle posledni select?

Souhlasím  |  Nesouhlasím  |  Odpovědět
a  |  13. 01. 2008 17:38  | 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Pavel Riedl  |  26. 06. 2006 06:04  | 

závěry srovnání se shodují s mými (našimi) zkušenostmi.
Řečeno slovy klasika: Oracle úspěšně řeší problémy, které u MS nemohou vzniknout...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Pavel Riedl  |  26. 06. 2006 06:12  | 

Zajímavý článek s diskuzí na tato témata jse na www.dbsvet.cz.
Pokud máte chvilku, stojí za přečtení:

Diskuse:Co vám vadí na Oracle?
http://www.dbsvet.cz/comment.php?akce=fullview&cisloclanku=2006041002

a pro změnu:

Diskuse:Co vám vadí na Microsoftu?
http://www.dbsvet.cz/comment.php?akce=fullview&cisloclanku=2006051601

Souhlasím  |  Nesouhlasím  |  Odpovědět
qV9mA8Ql6S  |  14. 09. 2006 21:44  | 

d4vq1D2OeuX Z8hofZWmE2AIqE i9b2BiR8wZ

Souhlasím  |  Nesouhlasím  |  Odpovědět
ja  |  26. 06. 2006 07:07  | 

Takove testy dela MFdnes taky.
Spis se mi zda, ze jim nekdo poradil test nebo metodiku.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Joker, Joker  |  26. 06. 2006 07:16  | 

Pobavil mě ten závěr:
"Sice z těch studií nemůžeme vyvozovat nějaké smysluplné závěry, ale je dobře, že je máme"

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr Souček  |  26. 06. 2006 07:49  | 

U podobných studií je vždy zásadní informace, kdo je platil - a ta informace v článku není.

Souhlasím  |  Nesouhlasím  |  Odpovědět
azor  |  26. 06. 2006 08:05  | 

to je snad vidět z článku - Microsoft

Souhlasím  |  Nesouhlasím  |  Odpovědět
molak  |  26. 06. 2006 09:34  | 

Microsoft OLE DB Provider for SQL Server error '80040e10'

Procedure 'sp_FORUM_GETSELECTED' expects parameter '@p_s_Art_ID', which was not supplied.

/mod_Forum/Reply/Default.asp, line 29

Souhlasím  |  Nesouhlasím  |  Odpovědět
MM  |  26. 06. 2006 09:56  | 

A ty si myslis, ze ta chyba je sposobena Microsoftom? Tak sa trochu spamataj a neries ftakoviny...

Souhlasím  |  Nesouhlasím  |  Odpovědět
sr  |  26. 06. 2006 09:58  | 

tahle chybová hláška se na zive.cz objevuje v jednom kuse. Když je administrace MS serveru tak jednoduchá, tak proč to neopraví?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Arvelius  |  26. 06. 2006 10:01  | 

protože jsou to lemplové

Souhlasím  |  Nesouhlasím  |  Odpovědět
MM  |  26. 06. 2006 12:34  | 

Ako sam mozes vidiet z popisu chyby, tak je to programatorska chyba (procedura ocakavala nejaky parameter naviac, ktory jej nebol dodany), a nie administratorska!!! Treba trosku citat alebo reagovat len vtedy, ked tomu rozumies
 
Musim podotknut, ze taketo chyby sa vyskytuju v praxi dost casto, ze programator opravi jednu vec, ale nejaka dalsia prestane fungovat - co je presny pripad tejto chyby.

Souhlasím  |  Nesouhlasím  |  Odpovědět
sr  |  26. 06. 2006 14:30  | 

jak si sám můžeš přečíst (poměrně často) na stránkách zive.cz, jedná se o chybu, kterou nikdo neopravil. Je jedno jestli je administrátorská nebo programátorská - je to chyba. To znamená, že když přijdu na tenhle web a SQL server mi vyhodi nějakou hlášku, tak je mi úplně jedno, proč to udělal. Tak ať to opraví a nebo přejdou na něco lepšího.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Izak  |  26. 06. 2006 17:02  | 

A hlavne kdyz na to kliknu znovat, tak to jede .... kdyz je chyba v programu tako nefunguje ne, a ne ze kdyz udelam 3x to same tak to 2x projde a jednou ne.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Portos  |  27. 06. 2006 09:31  | 

a nebo tohle:
 
Microsoft OLE DB Provider for SQL Server error '80040e31'
Timeout expired
/mod_ListOfArticles/ListOfArticlesTITLE_INC.asp, line 115

Souhlasím  |  Nesouhlasím  |  Odpovědět
mysi  |  26. 06. 2006 12:48  | 

To nema s administraci DB serveru nic spolecneho, to je problem tohoto zbastleneho webu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vetrak  |  26. 06. 2006 18:43  | 

Uz sme to riesili minule. Tento web je verejnou hanbou Computer Press

Souhlasím  |  Nesouhlasím  |  Odpovědět
Karel  |  26. 06. 2006 20:37  | 

Problém je v tom, že kvalitní admin podle té studio pořád stojí těch 80 000 USD a to holt živě se zablokovanýma bannerama těžko vydělá.

Souhlasím  |  Nesouhlasím  |  Odpovědět
sr  |  26. 06. 2006 10:04  | 

tyhle Microsoftem zaplacené testy mě vždycky dokážou pobavit, hlavně tím, jak jsou průhledné. Zkusím přirovnat k autům. Představte si, že máte dvoumístné sportovní auto Porsche a pětimístné Porsche SUV. Sporťák přepraví z Brna do Prahy 2 lidi za 2 hodiny. SUV přepraví s Brna do Prahy 5 lidí za 3 hodiny. Kdo je rachlejší? Samozřejmě sporťák. Teď se zeptáme jinak. Za jak dlouho přepravíte z Brna do Prahy 5 lidí? SUV za 3 hodiny a sporťák? Cesta tam, zpátky, zase tam. No a vítězem je SUV. Takže testy jsou celkem k ničemu. Vyberu jednu úlohu, která jde MS databázi nejlépe a srovnám ji s databázi Oracle a mám víteze. Určitě je dost podobných studií, ve kterých MS prohrává.

Souhlasím  |  Nesouhlasím  |  Odpovědět
sr  |  26. 06. 2006 10:06  | 

sorry za chyby a překlepy

Souhlasím  |  Nesouhlasím  |  Odpovědět
sr  |  26. 06. 2006 10:06  | 

sorry za chyby a překlepy

Souhlasím  |  Nesouhlasím  |  Odpovědět
&  |  26. 06. 2006 10:37  | 

Zas nejaka reklama na M$. Tyhle triky uz nefungujou. Nezavislych nestranych a spravedlivych srovnavacich testu placenych M$ tu uz bylo... A jeste ty blaboly na konci clanku me opravdu rozveselily, redakkce zive vubec neleze do zadku MS ;@)

Souhlasím  |  Nesouhlasím  |  Odpovědět
bobik  |  26. 06. 2006 10:57  | 

Naprosto souhlasím, zajímalo by mě o kolik vyjde levněji zaplatit si článek jako tajnou reklamu oproti tomu, aby MS zlepšilo kvalitu svých produktů 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Standa  |  26. 06. 2006 10:39  | 

No ale to nejdulezitejsi tam neni. Na jak dulezitejch (drahejch) projektech se to pouziva.
Kdyz jsou to vetsinou projekty jako zive.cz tak si samozrejme zaplatim levnyho programatora a levnyho administratora. Ale kdyz mam bankovni aplikaci ktera musi bezet 24/365 tak si radeji zaplatim drazsi reseni ktere mi ovsem bude lepe fungovat.

Neco v tom smyslu jedu ven a chci si koupit obleceni. Kdyz vyrazim 20 km za barak tak si ho klidne koupim u rakosniku i kdyz vim ze se mi za 14 dni rozpadne, ale kdyz jedu na hory do 4000metru tak si koupim drahy a kvalitni obleceni ve specializovanem obchode.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Smx  |  26. 06. 2006 11:05  | 

Já chci databázi, která bude mít výkon Oracle a uživatelské prostředí MS SQL Serveru..

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vetrak  |  26. 06. 2006 18:46  | 

Skus MySQL

Souhlasím  |  Nesouhlasím  |  Odpovědět
ripper  |  26. 06. 2006 20:49  | 

Vtipe,mysql je proti mssql a oracle jako hracka pro deti...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vetrak  |  27. 06. 2006 05:43  | 

Ty este asi zijes v casoch MySQL 3.23. Dnes mame verziu 5.1

Souhlasím  |  Nesouhlasím  |  Odpovědět
Yaroukh, Yaroukh  |  26. 06. 2006 21:58  | 

ten smajlik je rozhodne na miste
neco jako indexovani 'ON lower(column)' uz to umi? (ja to teda hledal/zkousel marne)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Izak  |  27. 06. 2006 00:06  | 

Asy ne, lidi s MySQL me uz serou, furt s toho delaji neco, co to neni. MySQL je super odkladaci disk, je to rychle pro cteni a zapis se tam deje minimalne. Kdy budou furt pridavat fce, tak nakonec strati vyhodu a lidi prejsou na PostgreSQL (ktery je na slozite veci)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ibrahim Ibuzzy  |  27. 06. 2006 00:16  | 

Pak trebat zkusit Firebird. Cool db.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Honza  |  26. 06. 2006 12:10  | 

Zdravim, takhle blbou studii jsem snad nevidel. Porovnavat u databaze ceny? V tom pripade vede MySQL a PostgreSQL. Zadarmo.
Me osobne zajima vykon. Podobne jako treba u aut asi nikdo nesrovnava Skoda120 a Fabii (kdyz uz jsme u podobne skupiny) podle cen, ale podle vykonu, rychlosti, bezpecnosti ...
Pobavila me reklama na SQL server - u Xeroxu to zvlada 5 milionu zaznamu za den. To je bratru celych 50(!) zaznamu za sekundu. Fascinujici vykon!
Honza

Souhlasím  |  Nesouhlasím  |  Odpovědět
R.  |  26. 06. 2006 21:49  | 

Není v článku náhodou napsáno, že se porovnávají náklady na administrátory a ne na licence nebo výkon? Jestli je db zadarmo nebo ne je nepodstatné, pokud je administrátor šíleně drahý nebo tráví půlku pracovní doby hledáním dokumentace a informací na internetu nebo diskutováním s ostatními postiženými, jak něco vyřešit. Možná by se dalo přičíst k dobru, že pak po večerech odstraňuje chyby a vylepšuje kód, ale to se v přímé bilanci u zaměstnavatele neprojeví.

Souhlasím  |  Nesouhlasím  |  Odpovědět
j.  |  26. 06. 2006 13:03  | 

Tohle je neskutecna pitomost... Je to zhruba stejne jako porovnavat rychlost vyvoje programu "hello world" v basicu a v C. Jenom to. ze kazdej stredoskolak s podstatne nizsimi mzdovymi naklady to dokaze naklepat rychleji v basicu, znamena to ze C je nanic?
Kdyz nekdo chce porovnavat 2 produkty, tak at to dela komplexne a nevybira par vlastnosti, jinak je to neskutecny paskvil s nulovou vypovidaci hodnotou.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Hopsinka  |  26. 06. 2006 19:27  | 

Jeden priklad za vse. Vezmete si napriklad nabidku funkci na praci s datumem. Microsoft ji ma totalne tragickou. Zaokrouhlovani zadne, aritmetika tristni. Napriklad toto zadani : Vypoctete posledni den predchoziho mesice.
Oracle :  trunc(sysdate,'MONTH')-1
Microsoft : dateadd(day,-1,cast(cast(Datepart(month,getdate()) as varchar) + '/1/' + cast(Datepart(year,getdate()) as varchar)  as datetime))

Souhlasím  |  Nesouhlasím  |  Odpovědět
RADl0PASlV  |  26. 06. 2006 19:58  | 

Microsoft: GETDATE()-DAY(GETDATE())

Souhlasím  |  Nesouhlasím  |  Odpovědět
Hopsinka  |  27. 06. 2006 09:46  | 

A kam se ztratilo to zaokrouhleni na pulnoc ?
O tom prave byla rec ..

Souhlasím  |  Nesouhlasím  |  Odpovědět
abcdef  |  26. 06. 2006 20:06  | 

že by ten Oracle programátor o víkendu pracoval na cirkulárce a pak ten kód musel ťukat jen jedním prstem ?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Karel  |  26. 06. 2006 20:40  | 

Hopsinko, z tebe programátor nebude. Na druhou stranu je to úžasně složitý způsob jak to spočítat a musím přiznat, že sám bych na něj nepřišel.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Izak  |  27. 06. 2006 00:14  | 

Jo a i kdyz je Oracle divna DB a jeji instalace je hrozna, integrace javy je tragicka.

Tak umi hezke clustery, napr nove zavadi klon GFS znamy z Linuxu a AIXu, ktery je upraven pro DB (GFS ma vice journalu primo v FS pro kazdou masinu)
a pak 2 servery pripojite ke stejne oblasti (FC pole) a mate 2 autonomni servery ze stejnymi daty, zatez se rozklada.
No a na AIXu to bezi na CPU Power, takze na BD idealni .... Go deti s M$ go na pisecek.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vasik  |  27. 06. 2006 20:49  | 

Mě by spíš zajímalo, zda ta skvělá naprogramovaná řešení potom někdo pořádbně ozkoušel, že perfektně fungují a pod zátěží.
My jsme ve firmě dělali mnoho náročných databázových aplikací, šlo o OLTP zpracování, spousta démonů makala nad stejnými tabulkami. Programovali jsme to pro Oracle, skutečně to trvalo dost dlouho, ale pak to běželo perfektně. Po delším čase jsme to museli přenést na MSSQL a dostali jsme se do neskutečných potíží, které u Oracle absolutně neexistovaly a nevznikaly.
Ani nebudu zmiňovat takové drobnosti jako nesrovnatelně delší a absolutně nepřehledný kód, protože Transact SQL ani nezná stupidní vektorové proměnné na rozdíl od PL SQL. Stejně tragické, nepřehledné a kód nafukující je, že triggery nejdou specifikovat tak jako u Oracle buď na tabulku nebo na každou měněnou řádku (jsou pouze na tabulku, kterou pak musím cyklem traverzovat). Bohužel u MSSQL ani nejde specifikovat zda se trigger vypálí BEFORE nebo AFTER změny řádku. Empirickým pozorováním jsme dospěli k tomu, že to zřejmě občas dělá BEFORE občas AFTER, dle potřeby.
Nicméně nejtragičtější problémy vznikly v transakčním přístupu a zamykání. Více procesů nad jednou tabulkou se u Oracle nepotlouklo a fungovalo to, protože Oracle má mechanismus automatického vytahování historických dat z redo logů během vykonávání selectu, o kterém se MSSQL ani nezdá. To se mimo jiné projevuje např. implicitní read-only transakcí při každém selectu, kdy všechna data ze selectu jsou konsistentní k času zahájení selectu bez ohledu na jeho trvání, ta změněná během trvání selectu si Oracle automaticky vydoluje z rollback segmentu (jejich historický stav). Tudíž se například nemůže stát, že obyčejný select zůstane viset protože narazil řádek, který má jiný proces zamčený pro zápis, což se běžně děje u MSSQL serveru. Oracle v takovém případě prostě automaticky vydoluje původní hodnotu a select  běží aniž si kdokoliv čehokoliv všiml nebo musel něco programovat. Prakticky žádná čekání, žádné deadlocky. V momentě přechodu na MSSQL neustálé problémy tohoto druhu.
Takovýchto synchronizačních a dalších potíží vznikla celá řada, takže celková doba vývoje pro MSSQL pak byla o hooooodně delší než pro Oracle a některé problémy se beze zbytku vyřešit vůbec nepodařilo.
Možná to není typický případ, asi každý nepíše běžně backendové aplikace s velkým počtem transakcí s dostupností 24/7. Můj dojem je že vývoj pro MSSQL je skutečně o dost rychlejší pro webové aplikačky, kde nevadí že se čas od času místo stránky objeví error hláška. Pokud se však budeme bavit o backend 24/7 processingu tak po předchozích zkušenostech s MSSQL jen přes mou mrtvolu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ja  |  28. 06. 2006 00:38  | 

Po precteni clanku jsem chtel nvarovani nestastnikovi, ktery by se na zaklade tohoto testu rozhodl nasadit MSSQL na velkou databazi nad kterou bezi aplikace, kde soucasne zadavaji data stovky uzivatelu, ale uz to tady je mnohem lepe a podrobne
Kdyby nekdo porovnaval DB/2 a Oracle tak prosim....

Souhlasím  |  Nesouhlasím  |  Odpovědět
PH  |  28. 06. 2006 14:05  | 

AD triggery - v MSSQL jsou AFTER, případně INSTEAD OF

AD transakce - měl by jste uvést, že toto se týká MSSQL 2000, verze 2005 již problém implicitních read-only transakcí řeší zavedením nové isolation level SNAPSHOT

Souhlasím  |  Nesouhlasím  |  Odpovědět
ptg  |  29. 08. 2006 11:02  | 

Oracle multiversioning nezabezpecuje redologmi ale undo segmentmi (rollback segmenty), redology su na uplne nieco ine (spolu s archivnymi redologmi na obnovu instancie po pade). Ale som rad, ze konecne niekto pomenoval hlavny pruser mssql a to je ze read blokuje write a write blokuje read, hahaha, ake ubohe. Neviem ci nejaka db okrem Oracle ma multiversioning, tusim najnovsi PostgreSQL ak sa nemylim.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jakub Hegenbart  |  11. 10. 2006 04:23  | 

Hehehe Vymyslel to Jim Starkey, takže Firebird to má už nějakých dvacet let …

Souhlasím  |  Nesouhlasím  |  Odpovědět
petka  |  11. 10. 2006 12:10  | 

Ahojte všichni, četla jsem si vaše příspěvky. fakt super. Chtěla bych poradit, mám psát seminární práci o databázích, tak když by byl někdo tak hodný a napsal mi nějaké adresy stránek, kde je něco o tomto SW jakou je mysql a oracle. budu moc vděčná. taal@seznam.cz diky

Souhlasím  |  Nesouhlasím  |  Odpovědět
Zasílat názory e-mailem: Zasílat názory Můj názor

Aktuální číslo časopisu Computer

Velký test Wi-Fi mesh

Nejlepší hodinky pro všechny aktivity

Důležité aplikace na cesty

Jak streamovat video na Twitch