Vlákno názorů k článku Korelované vnořené dotazy: proč nepoužívat a čím nahradit od LENIN POWER! - Kdyby autor radsi misto obecnych reci 'komercni databaze'...
-
LENIN POWER! (neregistrovaný)Kdyby autor radsi misto obecnych reci 'komercni databaze' jasne napsal ze pgsql neumi konstrukci WITH a myslim ze tomu druhymu co neumi (OVER & spol) se rika warehouse/windowed dotazy. byl by clanek hodnotnejsi.
MySQL tohle umi? Oracle/db2/mssql to umeji vsechny.
Jinak bych doporucil trochu odbornejsi clanky http://database-programmer.blogspot.com/
btw zrovna jsem zmeril rychlost pgsql pri obnove db. load 2.5GB dumpu trval hodinu na masine s raid1 15k rpm disky. To je fakt db vhodna pro velke objemy dat, me se db obnovuje ze zalohy 100GB za hodinu a jeste nadavam jak je to neskutecne pomalej soft. Ted vidim, ze si toho mam zacit vazit. Az na nas dopadne americka krize pac vetsina nasich zakazniku jsou amici, budeme muset zacit pouzivat OSS soft. -
WITH aneb CTE slouží řeší hiearchické dotazy - tudíž pro tento článek off topic. Analytické dotazy (warehouse/windowed) nepodporuje žádná OSS databáze, takže proč bych o nich psal. Existuje komerční odnož pg - Bisgres, který je snad používá. Jinak tento článek je určený hlavně začátečníkům v SQL, kteří stále vesele používají korelované dotazy, a to i na Oraclu nebo SQL serveru - přestože tam je k dispozici dost solidní náhrada - včetně OLAPu, který celou tuhle oblast řeší jinak a lépe.
Kdyby si Amicí nehráli na spasitele, a nenasrali hned po invazi Iráčany masivním rozprodejem ropného průmyslu US firmám, nebyli by teď v prdeli. Nicméně si nemyslím, že by firmy byly nějak nucené přecházet na OSS. Oracle má poměrně velké finanční rezervy, takže patrně razantně sníží ceny, stejně tak jako Microsoft a IBM. Jinak Javisti by si měli zvykat na horší platy - a nebo se začít dívat směrem na Rusko.
Proč je u Vás pg tak pomalá netuším, musel bych se na to podívat. -
ju. Použití CTE je o něco širší nežli pouze na hierarchické dotazy, i když si myslím, že hlavně u nich se člověk může s CTE setkat. Syntaxe CONNECT BY Oracle je jednodušší, klasičtější. CTE je ale univerzálnější: http://www.ksi.mff.cuni.cz/~pokorny/dj/prezentace/2_73.ppt . Čím dál se SQL posouvá od čistě relačního modelu, tím je to s přirozeností, čitelností a jednoduchostí horší :(. Ukázkou je CTE. Navíc, kromě DB2 si jak Microsoft, tak Oracle berou ze standardu jen části, které se jim hodí, což k ničemu dobrému nepřispívá. Do ANSI SQL se navíc dostává něco z Oracle (analytické dotazy), něco z DB2 (CTE), a občas některé rozumné věci se do standardu nedostanou. Např. Váš příklad se v dá poměrně jednoduše napsat jak ve Firebirdu, tak PostgreSQL (v pg: SELECT col1 FROM generate_series(0,100) temp1(col1)).
Generovat vzestupnou řadu rekurzí (což dělá Váš příklad CTE) je samo o sobě docela hukot. Podobné příklady se používají v učebnicích (patrně proto, aby se ukázalo, jak SQL může být komplikované), podobně jako korelované poddotazy. Praxe je trochu jiná - víc se uplatní procedury. -
LENIN POWER! (neregistrovaný)postgres sql si taky bere z normy jen to co mu vyhovuje, kuprikladu fulltext nema podle normy, navic ignoruje de facto prumyslove standardy (Oracle/db2 kompatibilni syntax). Kdyz neco nedefinuje norma dostatecne presne, tak je to v pgsql vzdycky jinak nez v Oraclu.
Jinak CTE neni hukot, hukot je select dynamicky generujici jine sql statementy, komunita db2 si na tom zaklada. Nekteri lide zjevne nemaji radi stored procedury a nechteji tohle delat v klientu.
db2 ma connect by taky, zrovna jsem si to zkusil.
1 SELECT name,
2 LEVEL,
3 salary,
4 CONNECT_BY_ROOT name AS root,
5 SUBSTR(SYS_CONNECT_BY_PATH(name, ':'), 1, 25) AS chain
6 FROM emp
7 START WITH name = 'Goyal'
8 CONNECT BY PRIOR empid = mgrid
9 ORDER SIBLINGS BY salary; -
Kupodivu existuje standard na fulltext (je částí SQL/MM), který ovšem není žádnou databází implementován - i když pg by se měl alespoň jedním operátorem ke standardu přiblížit. Cílem PostgreSQL není být Oracle kompatibilní databází, ale ANSI SQL kompatilní, o to se snaží komerční odnož EnterpriseDB. Navíc extenze ANSI SQL podporují minimálně dva různé nekompatibilní zápisy: klasické funkce nebo metody, takže je v tom stejně hokej. Zatím pg implementuje jen věci z ANSI SQL:200x core.
-
Honza Kral (neregistrovaný)V cem presne je oracle syntaxe mene univerzalni? napriklad ze nepodporuje NOCYCLE a musi se to obchazet silenymi hacky? U Profesora Pokorneho (kdyz uz citujeme) se na prednaskach ukazovalo jak se tomuto vyhnout pomoci toho, ze si postupne do VARCHAR policka ukladam cestu kterou jdu a v kazdem kroku kontroluji zda uz jsem tam nebyl, to mi vubec neprijde elegantni, natoz vykonne.
Slidy z teto serie bych nebral zas tak vazne - jsou to referaty studentu !
CONNECT BY je minimalne stejne silne jako CTE (CTE se pomoci toho da nasimulovat) a ma nejakou funkcionalitu navic (napriklad jiz zminene NOCYCLE, ktere mnoho veci usnadni) -
noname (neregistrovaný)K obnove dat - porovnavate hrusky s jabkama
obnova neceho na RAID1 disky bude podle kvality radice dost pomalejsi nez na stejne disky bez RAID1 !!! (U raid1 se musi vse napsat dvakrat, cteni rychlejsi je).
Predpokladam, ze stroj s 100GB databazi ma RAID5 pole s vice nez 3 diskama, nebo jeste lepe SAN a pak je pochopitelnym omezenim sirka linky k diskum a ne disky jako takove.
Mimochodem I na SAN radici se necha jemnou upravou rozdeleni pomeru read/write cache pomerne zasadne menit rychlost disku z pohledu systemu.
