Názory k článku
[ ( LEFT|RIGHT [ OUTER ])| INNER ] JOIN v SQL

Clovek zvladne SQL az kdyz pochopi:

0. jak kodovat kvalitni obsluhu chyb v Oraclu vcetne race conditions. Typicky
priklad je nechat nakodovat dilema insert or update
1. writeable cursory a jejich problemy
2. isolation levely + zamykani
3. dist. transakce vcetne recovery mechanizmu

Programatori nemaji s joiny moc problem. Ale pokud neumi tyhle veci, tak jsou nepouzitelni pro kazdy projekt kde zalezi na integrite dat. Ackoliv to neni zadna high technologie vetsina co se mi hlasi na to nema, nechce se to ucit, radsi si najde jine misto, je s tim mene prace.

Bože, kam jsme se to dostali... A co neoraclisti, třeba uživatelé Firebirdu a PostgreSQL, my se taky máme učit Oracle? ;-) (Pěkně děkuju, nemám zájem.) Jinak s těmi dalšími třemi věcmi souhlas, jemné zacházení s transakcemi a kurzory je docela důležité znát, asi v jakémkoli transakčním systému, nejen v databázích. :-)

A ty příklady SQL kódu, to je taky masakr... Teda ne že by nebylo dobrý vědět, jak se některý věci dělaj, když není zbytí, ale číslovat řádky tím self joinem...no jasně, znám i typový systém pro Lisp napsaný v lispovském dialektu Prologu využívající sequent calculus. Taky to funguje...asi podobně jako tohle. :-)

S ohledem na to, že PL/SQL je asi nejpropracovanější procedurální jazyk na straně RDBMS, tak i neOrákulisti by měli tušit, jak vypadá Mercedes mezi Oktávkami.

Ja bych spis rekl Oktavka mezi Trabantama - PL/SQL je dost priserny jazyk, protoze do nej byly casem dolepovany dalsi a dalsi funkce je to na nem dost videt... I kdyz takove TSQL (z MSSQL databaze) je jeste o chlup horsi, to je fakt.

S Firebirdem se už dá používat i oraclí PL/SQL, a to prostě tak, že se vezme PL/SQL soubor z oraclí aplikace a načte se u konkurence. Správně říkáte "mercedes mezi oktávkami", ale já bych to poupravil na "jednooký mezi slepými". Díky, ale já si radši dopíšu ten integrovaný dotazovací jazyk, abych se nemusel vůbec mrcasit s SQL a měl relační kalkul podle potřeby mezi jakýmikoli daty. :o)

A mimochodem, nepropracovanější procedurální jazyky na straně databáze obecně jsou Lisp a Smalltalk, příslušné produkty si jistě dohledáte sám. :o) Obojí umím mnohem lépe než Adu :) (Páč PL/SQL je Ada coby transvestita.)

tohle neni potreba vubec znat, na tohleto jsou uz dneska nastroje, ktere to udelaji mnohem lepe nez clovek. Mockrat jsem to testoval.

Pravda, tyhle high-end nastroje nejsou zrovna nejlevnejsi ale nahrazuji hodne lidske prace, takze ROI to ma.

No dovolim si nesouhlasit. Kdyz spravujete DB o velikosti pouhych 1-2 TB a jede ciste v OLTP rezimu se 4 tisici concurrent sessions, tak jsou to sakra dulezite veci...

Tak to oraclisté mají blbé. :) Já se pohybuju jen v komunitě uživatelů Firebirdu, ti se v tomhle vzdělávají poslušně a vzorně, protože defaultní nastavení (RW přes všechny tabulky v transakci, REPEATABLE READ implementovaný přes verzovací snapshot) by je brzy vytrestalo, zatímco při dobré znalosti toho, jak nahintovat enginu, co budu s čím provádět (páč RDBMS není věštírna...teda možná až na Oracle :-D) se to odmění pěkným throughputem. Nedávno na to dojeli pánové ze Sunu, co přišli předvést výsledky svého benchmarku Firebird vs. PostgreSQL, ale nenapadlo je, že se snapshoty budou ty firebirdí transakce jaksi pomalé... ;)

Holt ti páni ze Sunu jsou už odvyklé téhle Alchymii. PostgreSQL nemá potřebu hintů a ani spekulací s isolation levels. ;-)

Opravdu nemá? Takže databáze sama pozná, že chci REPEATABLE READ místo defaultního READ COMMITTED? ;-) Já nevím, možná, že se s tím takříkajíc "se*eme zbytečně", ale těch tisíc paralelních připojení na jeden PC server bez problémů za to stojí, ne? :-)

To nepozna, ale nezastavi se mi kvuli tomu aplikace. Neni tam tak razantni rozdil mezi temito rezimy.

No ona se nezastaví ani u Firebirdu, ale rozdíl tam nepochybně je. :-) I když FB překousne opravdu lecjaké prasárny.

A těch několik tisíc paralelních připojení bych docela rád viděl. Jsou o tom nějaké detailnější informace, než že to běží na jednom serveru někde v Rusku?

Myslím, že to zmiňoval to třeba ten pán, co měl přednášku na jedné z těch dvou firebirdích konferencí v Praze. :-) Rusko nevím, vím jen o Brazílii s 10TB databází, ale co vím, je to, že v dvouvrstvém modelu není problém něco kolem osmi set klientů, a s middlewarem několikanásobek (i to tam padlo). Bohužel, totiž, co to povídám - bohudík jsem to v životě nepotřeboval a nejspíš ani nebudu, já spíš embedded věci. :-)

Ale vůbec ne, Oraclisti to mají dobré, mají šanci najít co DB vlastně dělá. Nevím asi jsem hloupej, ale nikde jsem nenašel přehledně popsanou matematiku, jak PgSQL/FB stanovuje cenu přistupové cesty. Jinak názor níže, že Pg nemá potřebu hintů je celkem veselý. Pokud nevíte jak DBMS stroj (např. rozhodnutí o použití indexu) funguje tak v explain uvidíte index-scan (paráda), ale table scan bude lepší. Třeba proto, že data vznikají náhodně v čase call-data-record. Potom část dotazů může být lepší s indexem a něco jiného s hintem na potlačení indexu. Já se obecně hintům spíše bráním, protože většinou dobře platí pro okamžitý stav distribuce dat.
Dotaz k Vaší komunitě FB, jak je na tom optimalizátor s odhadem ceny pokud je vkládaná hodnota XXX integer (5,6,7,8,9) a potom dáte dotaz XXX > 5.5 and XXX < 8.2 nebo XXX < 4? Pokud Vám explain vrátí cardinalitu (počet řádků) v prvním případě 3 a v druhém 0 řádků pak je to fajn, ale třeba tohle Oracle korektně dořešil až u 10.1.0.4. Potom si zkuste to stejné, datový sloupec bude číslo, ale vložené zase integery, jak se s tím opt. popere.

Např. http://www.gtsm.com/oscon2003/toc.html

S tím si dovolím nesouhlasit. To jsou hodně specifické záležitosti jak pro Oracle, tak pro konkrétní aplikace. Třeba kurzorům je lepší se vyhnout. Samozřejmě, pokud se přepisují 30 let staré aplikace, tak to moc dobře nejde, a taky to je důvod, proč se kurzory do SQL přidaly - jinak tam nemají co dělat. Ne, že by to nebylo důležité, ale jádro SQL vidím jinde a to v operacích s relacemi. Navíc mám jinou zkušenost. Skutečně pro řadu programátorů je JOIN problém. Ti, co řeší isolation levely, už jsou opět někde jinde.

SQL není pouze PL/SQL. Se staršími verzemi Oraclu jsem nikdy nedělal, takže nevím,jestli tam kurzory byly od samého počátku nebo ne. Ale třeba u MSSQL se kurzory přidávali. A v samotném SQL, coby jazyku, je úloha kurzorů docela podružná a redundantní (původně kurzory byly implementační záležitostí). Prostě kurzory v SQL jsou taková diskutabilní a kontroverzní záležitost.

PL/SQL hlavně není!! SQL. SQL je neprocedurální, PL/SQL je jeho procedurální nadstavba... Ale to jen na okraj.

Částí standardu SQL je SQL/PSM, což je procedurální rozšíření SQL :). Jinak souhlas, gro SQL je neprocedurální.

To taky netvrdím, a ve článku několikrát zdůrazňuji, že záleží na datech, db stroji, indexech, úloze, aplikaci, zatížení. Ale budu tvrdit, že bez znalosti standardu, coby jazyka, těžko budete psát optimální selecty kdekoliv. A zase je otázkou, co je optimální. Jinak bude vypadat optimální dotaz v aplikaci s 10K uživateli a jinak v aplikaci s 10 uživateli, pokud jako jedno z kritérii budu náklady na programátora. V aplikaci s tisícem uživatelů se musíte s časy dostat na desítky milisekund. Pokud máte desítky uživatelů tak tam časy v řádech stovek milisekund až tak nevadí. Prioritou je znalost jazyka. Bez ní je to bastlířina. Sekundární je znalost konkrétního stroje. Bez ní je to alchymie.

kolik % odhadujete, ze je projektu, kde zalezi na takove intergite dat jak pisete?

Rekl bych ze to jsou vsechny projekty kde jejich vlastnik nebo designer pochopil ze data jsou ta nejcenejsi deviza. Tyto projekty se v soucasne dobe typicky poznaji podle toho, ze nejedou na MySQL.

A nyni uz dalsi cilso tolik oblibeneho MySQL bulletinu!
transakce? to se dela na aplikacni urovni. Spravny programator to nakodi.
joiny? To se dela na aplikacni urovni taky
foreign klice? To jako myslite tu vec co brzdila Oracle7 o 100% pri updatech? Jasnacka, syntax podporujeme
nejake normy? bah, overrated. I kdyz pravda v 5.0 jsme prekodovali joiny tak, aby konecne vracely spravna data aletovite customeri si stezuji ze jim to rozbilo aplikace, tak v 6.0 to zase vratime nazpet.
NULL hodnoty? bah, kazde male dite prece vi ze misto NULLu chytre databaze mysli za kodera a ukladaji DEFAULT hodnotu
chcete vladat retezce do integer sloupcu? U nas muzete!
Prodluzte si s nami dovolenou, jen u nas ma unor 31dnu!
Kdyz zhavaruje tabulka MYISAM garantujeme ze neprijdete vice nez o 1% ulozenych dat.
Pravda v innodb mame jeste nejake races, takze recovery nekdy vyhnije. Proste si od nas kupte nas replikacni software.
Rollfoward recovery? To myslite tu zbytecnost z Oraclu5? Proc je ten Oracle tak nemoznej a porad implementuje veci co brzdi databazi! Podivejte se na nase benchmarky, jsme 10x rychlejsi!
Neztracejte cas s testovanim navratovych hodnot! Pro lepsi efektivitu programatora pro vas mame pripravene prikazy INSERT DELAYED a INSERT LOW PRIORITY
Triggery a primary klice? To myslite, ty viry co vam zabranuji manipulovat s daty jak se vam zlibi? Uznavame, to musi uz jednou prestat a proto jsme pro vas pripravili .... INSERT IGNORE!
Musime vam s politovanim oznamit, ze jsme byli nuceni zrusit podporu elastickych tabulek a tim padem i vami tak oblibene syntaxe INSERT INTO tbl_name (a,b,c) VALUES(1,2,3,4,5,6,7,8,9); Fakt nas to mrzi, ale porad nekteri idioti do toho vrtali a rvali na nas SQL92!
Radi bychom vam predstavili taky nase skvele insert/update kombo INSERT INTO ... ON DUPLICATE KEY UPDATE x=x+1; Tento prikaz vam umozni rychle updatovat vase tablice. Proto jsme ho pochopitelne nakodili. Narozdil od ostatnich nasich prikazu, ktere jsou taky rychle jen tento uber rychly! Je tak rychly, ze se provede driv nez to nase replikace vubec zaznamena. Jeho pouzitim doslova predbehnete dobu! Jeho pouziti doporucujeme zejmena v aplikacich, kde je dulezita rychlost, napriklad pri zpracovani plateb kreditkou.
Prestante uz konecne resit nejake row level/ block level locking ci MVCC. Radi bychom vam predstavili nase vysoce kvalitni zamky.
Nase zamky nejsou zadni drobeckove u nas se netroskari - zamykame cele tabulky a vase data tak budou pred ostatnimy uzivateli v bezpeci.
My svou praci neodbyvame, kdyz neco zamkneme, tak to drzi! Nase zamky drzi lepe i nez vase connection. Kdyz tam spadne, nebojte se, nas zamek bude drzet dal, na to vemte jed.

Integrita dat je spatna pro vas byznys! S vyuzitim spravne databaze spojene s kvalitnim koderem a nasim e-shop produktem muzete bez problemu koupit 10 vyrobku a prodat jich 12! Tim vydelate 20%! Uvedomte si, ze jsou to penize, ktere vam padaji z nebe diky nasim kvalitnim a rychlym technologiim!

:-))))))))))))))))))))))))))))))))))))))))))))))))))))))

Óóó díky. Tak jsem se už dlouho nezasmál. :-) Musím to dát přečíst svému kolegovi, který nedá na MySQL dopustit a když mu to říkám, tak furt plácá jenom nějaké MyISAM, MyISAM, MyISAM jako papoušek. :-D

mysql> SELECT DATE('2007-02-28');
+--------------------+
| DATE('2007-02-28') |
+--------------------+
| 2007-02-28 |
+--------------------+
1 row in set (0.00 sec)

mysql> SELECT DATE('2007-02-29');
+--------------------+
| DATE('2007-02-29') |
+--------------------+
| NULL |
+--------------------+
1 row in set, 1 warning (0.00 sec)


este sa mi ne za 5 rokov pouzivania mysql nestalo ze by som prisiel o data inak, nez zlyhanim 2 diskov z troch na raid5 poli... par krat sa stalo, ze zblbla ups, masina sla dole bez umountu a par tabuliek bolo oznacenych ako crasched, ale po repair table neprislo sa ani o bajt...

takych 90% z toho polousmevneho prispevku su bludy ludi, ktori pomyselne postupili v databazach hore, prestali sledovat vyvoj "podradnych" databazovych systemov a po zisteni, ze clovek nepracuje s oraclom je automaticky oznaceny za lamu...
Treba si uvedomit, ze su proste projekty, koli ktorym sa neoplati kupovat oracle.

To je prave ta chyba. Slusne vychovana databaze nemeni cokoliv na null, i kdyz je to chyba

postgres=# SELECT DATE '2007-02-29';
ERROR:  date/time field value out of range: "2007-02-29"

Takto se chova vychovana databaze. Nicmene MySQL lze take prepnout do ANSI kompatibilniho modu, kde se chova slusne. Je otazkou, kolik uzivatelu ji do tohoto rezimu prepne. Jinak to ja uz jsem toho videl. Borec uz to mel zmakle .. repair integrity, kterou ovsem nemel implementovanou, zvladl rucne za 10 minut. Nestacil jsem se divit, bylo videt, ze to nedela prvne. Jen jsem si rikal, kdyby to mel v transakci, tak nic takoveho nemusel delat rucne. A opet MySQL transakce podporuje, ale kolik aplikaci je psanych tak, ze pouziva transakce. Coz neni zalezitost jenom MySQL. Zazil jsem jineho borce, ktery tvrdil, ze transakce jen brzdi system na MSSQL a ze on je zasadne pouzivat nebude, neb neco jako izolaci nebo atomicnost nepotrebuje, neb ten system jede tak rychle, ze ta sance ze databaze vypadne a ono se to rozhodi, je minimalni - a jedna se o Microsoft Certificated inzenyra. Skutecne ta sance, ze dojde k rozpadu databaze je minimalni, jenomze pokud k ni uz dojde, tak mate vypadek a nepomuze vam ani deset svatych, jedine zaloha. S transakcemi je to riziko radove mensi. Cokoliv jde zbastlit, poctive remeslo je ovsem o necem jinem.

kdybych mysql5.0 nepouzival pro nektere lidi co ji vyzaduji (support mysql prodavame 3x draze nez support oraclu, pac vyzaduje vice lidske prace na zajisteni stejneho service levelu. napriklad neustale kontroly zda se data replikuji spravne), tezko bych vedel takovyto seznam jejich bugu a navic by mne byla uplne ukradena jako ostatni produkty ktery nepouzivam - je mi uplne fuk, zda tam jsou bugy ci ne.

Jinak nejlevnejsi Oracle stoji $5K a nejlevnejsi DB/2 stoji $3k. Ta DB/2 umi v teto verzi narozdil od Oraclu i HA fce t.j. failover/replikaci. To je tolik, co si nekdo nemuze dovolit zaplatit pro produkcni nasazeni? Spocitejte si jen naklady na administraci DB serveru rekneme za 5 let, kolik $$ stoji napriklad jen plat administratora. Pak poznate, ze napriklad ta cena DB/2 je jen kapka v mori.

Krom toho muzete mit dneska uz DB/2 zdarma a to i pro produkcni nasazeni (bez replikace/failoveru). DB/2 ale umi online backup, rollforward recovery a to se da pouzit misto builtin failoveru. DB/2 je databaze v tride s Oraclem.

http://www-306.ibm.com/software/data/db2/express/

Nepovazuji toho, kdo nepouziva Oracle za lamu, sam mam v produkci i pgsql a DB/2. Nainstalujte demo Oracle ci DB/2 otestujte poradne proceduralni jazyky, replikaci a autotuning db pak pochopite.

Krom toho muzete mit dneska uz DB/2 zdarma a to i pro produkcni nasazeni (bez replikace/failoveru). DB/2 ale umi online backup, rollforward recovery a to se da pouzit misto builtin failoveru. DB/2 je databaze v tride s Oraclem.

Online backup snad už dneska umí všichni, ne? InterBase (tehdy ještě pod tímhle názvem :-)) to uměla už před dvaceti lety, stejně jako dnešní odvozené databáze. Její administrace určitě nepatří k nejnáročnějším, stejně jako support (spíš člověk občas zapomene server v koutě a pak po půlroce zjistí, že opravdu pořád ještě funguje :-)). Nechápu, proč hopsat z MySQL rovnou na Oracle...

No, právě jde o to, že u normální databáze žádné REPAIR TABLE nepotřebuješ, prostě můžeš přijít k počítači, zmáčknout reset, a ono to naběhne samo a nic se neztratí.

Vase osobni zkusenosti jsou zajimave, ale mozna by neskodilo si MySQL opravdu vyzkouset. Pokud vam v dnesni dobe MySQL dela to co pisete, potom tomu proste nerozumite a bud se to naucte a nebo proste nepiste o necem, co neznate. Plati pro vetsinu popisovanych prikladu ;-)

Ačkoliv s Vámi v mnohém souhlasím a integrita dat je rozhodně nade vše, přesto musím mírně oponovat.

Asi Vám ušlo, že v mySQL nejsou pouze tabulky myIsam.
Transakční programy uměli psát dobří programátoři už v dávnověku a patří to ke zvládnutí řemesla. Že se o to databáze nestará ještě neznamená, že to nejde. Přinejhorším stejně jako u Oracle - pomocí temporary tabulek. Prostě žádné změny online a pouze opakovatelné akce. (Transakce znamená "včechno nebo nic". Nic to nutně být nemusí. Také si mohu požadovanou posloupnost zapsat a po pádu ji prostě dokončit).
Zachovat datovou integritu (například při kaskádovém mazání a větvení tabulek) dá trochu práce ale jde to.
S joiny na aplikační úrovni si - předpokládám - děláte prdel.
Foreign klíče nejsou podstatné - klíče známe a vhodný join dělá totéž.
DEFAULT hodnoty použít nemusíte.
Kdo nekontroluje vstupní hodnoty není programátor ale blbec.
Primární klíče se požívají běžně.
Triggery v aplikaci nahradit lze. (Aplikace snad ví, co děláte).

Dobře napsaný program v MySQL dá prostě víc práce vež v Oraclu a vyžaduje lepšího progamátora,

No právě. Pochopil bych, že někdo používá sw, který šetří práci a nevyžaduje elitní programátory. Proč ale používat sw, který práci nešetří?

Treba proto, ze nekdo chce proste jen hloupe uloziste na data, protoze to co dela, stejne musi delat aplikace ?

Třeba proto, že netuší, co obnáší napsat program ale ví, co stojí Oracle.

I v MySQL se dá psát slušně. Ale musí být k tomu chuť. A čas se to naučit.

To si nemyslím. Myslím si, že se přeceňuje prostředek a nedoceňuje kultura. V Javě, v Oraclu, v C můžete psát strašlivě, naopak viděl jsem čistý a čitelný kód v PHP nebo Visual Basicu. Slyšel jsem, že v Oraclu se píšou zvěrstva díky tomu, že ta databáze je velice tolerantní a optimalizér hodně napraví. Naopak ve Firebirdu, pokud nemáte opravdu dost znalostí a neděláte věci optimálně, tak to setsakramentsky poznáte na výkonu. Mnohem důležitější je ale kultůra která je v okolí, ve firmě, v komunitě. Když se dozvíte, že r.i. je na xxxx, pořádně se něco naučit je k ničemu, všechna školení taky a hlavně zítra musí být hotový kód, který vznikal bez analýzy a je slepenina všeho, co se ve firmě napsalo za posledních deset let aniž by o tom byla dokumentace, tak co z Vás vyroste. Hůl jako hůl, ale samuraj s ní dokáže něco jiného než vesnícký podomek. Hlavně by mělo být programování poctivé řemeslo. Ať používám cokoliv, tak to dělám co nejlépe. K tomu je ale potřeba rozhled, vědět co k čemu slouží, jaký to má efekt, kdy a jak se to používá. Kulturní efekt je znát na rozdílu ruby a phpka. Mezi nimi není rozdíl technický (pokud je, tak nikterak velký), ale mezi nimi je naprosto zásadní kulturní rozdíl (důraz na nástroje RoR, důraz na kvalitu kódu, důraz na radost z kodování, důraz na znalosti, nepřekrucování faktů). Nasát, naučit se dobře programovat, to je záležitost 2-3 let, a ještě musí být od koho se učit.

Moji studenti většinou znají MS Access, na který rychle zapomenou, poněvadž dostanou jen textovou konzolu. Používám PostgreSQL. Klidně bych asi mohl používat MySQL 5.x. Pro výuku samotného jazyka to nehraje roli (pokud se držíte standardu), a nepředvádíte, cože za skvělé věci v MySQL lze dělat a v ostatních databázích nikoliv.

Skvele! :)))

:D, az se budete divit, proc vas rols tak blbe jezdi s tim pluhem po poli, proc se tak blbe bori do bahna, proc ... tak pridte, vymenim toho vaseho rolse za traktor.

Jeste sem nevidel MySQL nasazeny na nejakem firemnim IS, ale jeste sem nevidel web bezici na oraklu.

Vy umite z webu poznat jaka je za nim databaze? ;-) A pokud mluvite o kodu, tak to bude spis prostredim, ve kterem se pohybujete ;-)

Nó, běžte pracovat do nějaké nadnárodní IT firmy a uvidíte tunu webů na intranetu i internetu, které mají jako backend Oracle. Možná i v MS.

Videl jsem oboji, a zadny rozdil v tom vetsinou neni :)

Něco takového mě taky hned napadlo. Páni podnikatelé (a abych jim nekřivdil, tak různí pseudo-IT-odborníci) často považují za "základní" ten stav, kam se horko těžko po dlouhém čase (a zkušenostech na projektu, které nováček prostě nemůže mít, pokud to už nedělal) dostali a rádi dávají ostatním pocítit, jak jsou "dobří". Když to jde ruku v ruce s nabídkou 20-30i tisíc hrubouš, tak je samozřejmě potřeba říct něco jako: "Děkuji, na shledanou!"

Ta skutečná deviza, která se ovšem na přijímacím pohovoru zjišťuje hůře, je, za jak dlouho je dotyčný schopen se na tu úroveň dostat. Páni podnikatelé by se často divili, jak to jde jiným rychle, ale to už samozřejmě nepřiznají...

Ty veci co jsem nastinil jsou vysvetleny velmi podrobne ve VS skriptech ktere mi tu lezi na stole. V zadnem pripade se nejedna o highend, ke kteremu se dobereme horkotezko dlouholetou praxi. Jedna se o zaklad, ktery se vyucuje na VS.

Je mi jasne ze nejen studenti, ale i vetsina SQL coderu co se sem hlasi o tom nema ani paru. Nikdy o tom neslyseli a ani nechapou proc by se to vlastne melo delat. Protoze je urovne ceskeho IT takova jaka je, mame proto tyto zakladni veci najednou prohlasovat za highend abychom zamaskovali svou neznalost? Prestanme si laskave toto nalhavat. Co budeme pokladat za highend priste? Referencni integritu? Triggery? Transakce?

a prestante mi tu machrovat s prachama. O tom to vubec neni. Budto to znate nebo ne. Jenom hlupaci argumentuji stylem: Prace kterou jsem odvedl je sice zprasena, ale to je tim, ze za to mam malo (nebo nic, kdyz se jedna o open source).

Jaky kdyby hudebni mistr hral jak prase kdyz bude hrat nekomu pro radost. Kdyz umite dobre hrat, tak to umite vzdycky. S programovanim je to stejne.

Neznám nikoho, kdo by se naučil programovat na VŠ - pokud to ovšem nebyl jeho koníček a neprogramoval "bokem". Školní příklady - s vynecháním všeho "nepodstatného" jako třeba datové kontroly - k tomu opravdu nestačí a pouhá znalost terminologie a syntaxe také ne.
A úroveň českého IT je taková jaká je právě proto, že se firmy nestarají o výchovu dorostu a co programátor, to samouk.(A nejen programátor).Dokonce jsem zažil šokující případ, kdy skušení kolegové své znalosti před těmi mladšími ukrývali, protože to považovali za svojí devízu na trhu práce a báli se konkurence! Všichni čekají, až k nim odněkud příjdou hotoví špičkoví pracovníci, protože proč by investovali do budoucnosti firmy a výchovy kádrů. Hlavně že je management dobře placenej.

Ano, s tim souhlas, 99% ITku v cr = samouci. Sam jsem jednim z nich a stav je jaky je predevsim proto, ze presne dle znameho porekadla "... a kdo to neumi, ten to uci ...", coz je ma osobni zkusenost ze vsech urovni skol v CR.

To ze je nekdo samouk ovsem neznamena, ze sve praci nerozumi (aby bylo jasno, nemluvim ted o sobe). Casto toho totiz takovi samouk vi o dane problematice mnohem vice, ze kdejaky diplomovany "od vseho neco".


----
K postu vyse, vazne me pobavi inzetaty typu "hledame vyvojare/programatora/databazoveho specialistu ... a nabizime uzasnych 15kKc ....". O tech penezich to je totiz vazeny pane Kolari predevsim, pokud chcete odpovidajici sluzbu, tak si ji budete muset odpovidajicne zaplatit. Uz vidim ty zastupy odborniku, kteri vedi, ze si firma za jejich praci bude uctovat tisice na hodinu, jak stoji celi nadseni frontu.

Pokud se vam zda nejaky OS produkt napsany prasecky, mate moznost, pocitam ze vyvojari prijmou s nadsenim nekoho, kdo veci rozumi a prispeje. Ono to totiz vetsinou funguje tak, ze kdyz potrebuju aby aplikace umela vec XY, tak si napisu vec XY a to ze neumi vec YZ, kterou by chtel pan Kolar je mi u ...

SQL učím, dokonce na několika frontách, a myslím si, že jestli něčemu rozumím, tak je to SQL. Znám i pár lidí, kteří dokáží naučit i programování, analýzu. Myslím si, že jste prostě měl smůlu. Ono to chce jednak vybírat, snažit se, a jednak mít trochu štěstí. Sám mám stavárnu a narazil jsem tam na lidi, kteří mě z programování vysvětlili fakt to co bylo potřeba - kdo znáte zejména dr. Demel případně dr. Hora, doc. Petr. A to byla stavárna (ČVUT, SI).

Zdravím autora a díky za článek. Oracle mě živí skoro 7roků a s klidem můžu říci: jestli něčemu nerozumím tak je to Oracle. Znám matematiku okolo CBO, fyzické uložení dat, částečně teorii množin (ze které relační model vychází) a zatím mám jen jednu OCA.
Abych věděl co to asi všechno umí, tak mi zbývá cca 7000 stran dokumentace SQL/PLSQL.
A to ty potvory vydaly v srpnu 11-ku :(((

Je fajn, že jsou v IT lidé i mimo obor (sám jsem strojař). Někdy je řeznický způsob řešení lepší než akademická debata. Prosím berte můj příspěvek s nadhledem. Všem dobrou noc.

Můj příspěvek o tom, že neznám nikoho, kdo by se naučil programovat na VŠ, nechtěl kritizovat úroveň výuky. Měl jsem spíše na mysli, že znalost teorie ještě nestačí. K využití těchto znalostí je potřeba praxe a ta se získává většinou až v zaměstnání. Programoval jsem v jednom jazyce 10 let a 10 let jsem se učil jazyk používat. S láskou vzpomínám na své začátky v sálovém středisku, kde byla dokonalá dělba práce (programátor pouze programoval) a starší kolegové nás učili všemu, k čemu za své praxe dospěli a ještě nám předávali různá udělátka pro zvýšení produktivity. Díky tomu jme se vyvarovali mnohým chybám a rychle jsme dosáhli jejich úrovně. Dnes co programátor to solitér, ve firmě má na starosti snad všechno s výjimkou úklidu, programy píše podloudně po nocích, protože v práci je co čtvrhodinu vyrušován, notoricky známé věci musí objevovat znovu a že píše programy špatně, na to příjde za 5 let, pokud vůbec.

Pracovník roste svými úkoly. Pokud mám znát všechno, co firma potřebuje už při svém nástupu, pak se už nemám co učit a budu jenom krnět. Práce v takové firmě nemá valný smysl.
A nejlepší odborník je vždycky ten, kterého si firma vychová.

+<nějaké_hodně_velké_číslo>... :-)

Misto programatora je predevsim o programovani a ne o vydelavani penez. K tomu jsou urcene jine pracovni pozice.

Primarni otazka neni za kolik, ale zda ma uchazec protrebnou kvalifikaci. Pokud ji nema, tak vubec neni o cem mluvit. Pokud ji ma tak je seznamen se systemem jak se plati.

O penezich to *vubec* neni. Naprosta vetsina totiz neplnuje vstupni pozadavky a ty co jimi projdou nevznasi zadne namitky ohledne penez. Ja nevim proc porad hledate problemy tam kde zadne nejsou.

Takže vy věříte, že zaměstnáváte špičku. Hm. Podle mého názoru jste roztomile naivní.

Anebo věříte, že existuje nějaké N, pro které je pravda, že "N blbců s formálním vzděláním je lepší než jeden talentovaný člověk". Ale v tom případě vás převálcuje indický offshore, neboť Čechy nedokáží takové N s dostatečně nízkou cenou dostatečně rychle vyprodukovat.

No, na tohle se už dá snad říct jenom: přeji hodně zábavy při hledání uchazečů, kteří vás uspokojí. :-D
Jen si musím opsat váš mejl, abychom se náhodou někdy nesetkali :-D

Integrita dat? Co to je?

Většinu webových programátorů v PHP tahle záhadná věc nezajímá. Jak docílíte integritu dat, když uživatel kouká na jakýsi výpis z databáze a pomocí AJAXu se mu dotahávají další kusy stránky?

Že záznam, který uživatel vidí, už nemusí vypadá úplně jinak a AJAX se ptá na něco, co už dávno neexistuje? No a co.

Jestli se uživateli stránka HODNĚ rozmrší, vždycky může dát RELOAD. Tak jakápak integrita. S těmahle blbostma táhněte někam do banky, normální programátoři to fakt nepotřebujou.

normalizace dat je taky napytel, je to sice napohled hezke a vseobecne uznavano jako dobry design. Ale kdyz mate velke tabulky tak si zatracene rychle zacnete uvedomovat jak pridani kazde dalsi tabulky do selectu brzdi.

Dnes neni zadny duvod pro normalizaci za kazdou cenu. Mista na disku a v pameti je vice nez dost a sekvencni pristup je rychly.

Sekvencni nacitani denormalizovane tabulky je mnohem rychlejsi nez behani po 3 ruznych tabulkach soucasne. Sekvencni cteni je minimalne 5-8x rychlejsi nez nahodny pristup a dnesni storage servery umi z pole sekvencne cist 2GBajty/sec. Pod pojmem storage server nemyslim zadny uber highend, ale nic zvlastniho bezne pouzivany stroj za cca $35K s rekneme 50ti lowend sata disky. Storage server s SAS 15k rpm disky ma podstatne lepsi prujezd, tomu taky odpovida cena.

Ona se taky databázová architektura nejdříve normalizuje (třeba až na 5. formu), ale pak se zase musí denormalizovat podle datové logiky a způsobu práce s daty. Univerzální architektura neexistuje.

A rychlost načítání není jediné omezení. Namátko - velikost tuplu,velikost rezervované paměti a další. Kvalita dat (je třeba si uvědomit, ře použití indexu je efeketivní při zhruba odfiltrování 20-50% záznamů, jinak se použije fullscan) je otázka, kterou je velmi brát v potaz!

Zkuste si auditovat pár shopů jako já a zjistíte, že to není pravda. Sekvenční čtení je samozřejmě rychlejší, mimochodem sekvenční čtení se použije i když spojujete tabulky, ale má jeden dost nepříjemný důsledek. Dost Vám zacloumá s cache. Přístup do denormalizovaných tabulek není tak častý (většinou se jedná o analýzy, reporty) a je mnohem efektivnější použít OLAP nebo materializované tabulky. Docela dost se setkávám s tím, že místo toho, aby ve firmě nasadili OLAP, tak právě vymýšlejí takovéto brikule. Tím problém nevyřeší, a ještě mají problém s hw. Hlavní důvod pro normalizaci je dekompozice dat. Pokud máte dobře dekomponovaná data, budou se dobře psát selecty. Pokud máte denormalizovaná data, pak v podstatě používáte SQL jen jako data storage, a vlastně SQL Vám je spíš na škodu než k užitku.

Nenormalizovane tabulky nejsou spasa vykonu, protoze kdyz najeky databazovy mag navrhne tabulku s 230 sloupci, tak je z toho i ten skvely Oracle na vetvi. A pri praci s PL/SQL existenci takoveto struktury primo ignoruje (zjisteno na Oracle 8-10i).

A co duplicitní (či spíše multiplicitní) data v takové nenormalizované tabulce? Uptdate musí být vážně záhul. Pokud si vzpomínám, takhle se programovalo před vynálezem databází za pomocí merge.

Hmm, no nevim, pracuju s takovou pidi databazickou(vsehovsudy 60GB), ale kazdodene mam chut rozbit jejimu navrhari hubu, jelikoz to co by se pri rozumnem navrhu dalo delat v jednotkach ms trva sekundy a to celkem bez ohledu na vykon HW ...

Takove veci jako zamykani se vyvojarum asi resit nechtelo vubec, takze stav kdy kvuli selectu do DB stoji 1/2 firmy je celkem normal ... no a nez bych se dockal od vyvojaru, vysesil sem si to radsi sam, stacilo semo tamo pridat index ...

Jste z Liberce.

Překvapuje mě, že cpete lidem Oracle a DB2, a přitom škudlíte na discích... :-D Vskutku profesionální přístup. :-)

• Supports up to 4GB of user data (in addition to Oracle system data) • Single instance only of Oracle Database XE on any server • May be installed on a multiple CPU server, but only executes on one processor in any server • May be installed on a server with any amount of memory, but will only use up to 1GB RAM of available memory

No to je výhra. ;-) S Firebirdem redo log nepotřebuju -> ušetřím na těch dvou discích. ;-) Raptor je taky polospotřební zboží, dyť už je dělají i "s okýnkem", bůh ví, co je to za mechaniku. :-/ A to "chytré pole" je přeci jen cenově někde trošku jinde, ne? BTW, žil jsem v domnění, že RAID 5 pro databázi s mnoha zápisy nemá smysl.

Díky za upozornění, ale já vím, co je Redo Log. Kdybych měl Oracle, určitě bych nějaký potřeboval a nějaký disk by se pro něj našel, ale naštěstí používám Firebird, který ukládá delta-komprimované zpětné verze řádků na totožnou databázovou stránku (což v drtivé většně případů ani nepřeteče, ani to nevyžaduje samostatnou diskovou operaci kvůli logu).

Nojo, ale nejlepsi featura kterou redo logy poskytuji je tzv. media recovery mode v Oracle terminologii AKA archivelog mode ... a to je opravdu super vec.

A po dobu deseti hodin ta data nebudou vůbec vidět, nebo to z toho logu bude engine tahat nepříliš efektivními metodami "bokem"? Já tedy nevím, ale snad všechny databáze se starají o to, aby se data flushovala na disk nějakým rozumným způsobem. :-) Pominu-li bulk load, tak nevidím potřebu zapisovat padesát MB za sekundu na jeden disk. Dvacet pět let nasazení a statisíce instalací prokazují, že i bez logu bokem to "just works". Čím neříkám, že log navíc není pěkný, zřejmě umožňuje nějaké ty vychytávky navíc, nicméně spousta lidí asi vyžije i bez nich. :-)

nojo ale redo log je naprosto mission critical feature, nebot umoznuje kontinualni zalohovani, standby mode, data auditing, flashback. Bez nej by to proste v produkci neslo.

fb online zalohovat jde sice diky MVCC, ale Oracle DB/2 by bez redo logu vubec nesly online zalohovat, pokud by nebyly na jednom zarizeni a zarizeni by umelo snapshoty.

Jeste je zajimave upozornit na to, ze DB/2 narozdil od Oracle pouziva redo logy i pro rollback.

Zajimave ze obe dve top db pozivaji misto multigeneracni architektury row, page level locky. Kterych tedy drzi pozehnane, koukam na muj Oracle a ma tak cca 160k aktivnich zamku a kdyz si spustim oracle jen sam pro sebe, tak 1 user connected 530 locks held :)

Sice nemusi delat garbage collection, ale zase jim dost nesvedci dlouhe transakce - znama Oracle chyba snapshot too old. po zkusenosti s pgsql bych rekl ze multigeneracni architektura je lepsi, ta garbage collection nema moc velkou rezii a obe dve DB scanuji periodicky DB aby si aktualizovaly statistiky, tak by mohli GC delat pri tom. Krom toho jde GC delat i prubezne pri nacitani stranky.

Proč se k tomuhle článku rovnou nepřihodilo i použití UNION?

Protože je UNION úplně něco jiného (a zase téma na celý článek).

... a vsichni volali nadsenim, jak je outer join nadherny a sql-cisar zjevne potesen prizni podanych vhodil do davu nekolik dalsich subselectu. Najednou zvolal maly chlapec ... 'vzdyt ten sql-cisar je uplne nahy' a dav si zacal septat ... slyseli jste, co rikal ten chlapec, pry na tom sql vubec nic neni, pry je to zbytecne ... a lide procitli a sql-cisare vyhnali ze zeme

Tohle není špatný nápad. V SQL nevzdělaných programátorů je 12 do tuctu a každá kapka osvěty se tudíž hodí!

a ktery smer osvety by jste preferoval - Kolarovsky nebo Stehulovsky ...

Jak se chova MySQL a ostatni DB ke slozenemu indexu? Staci mit slozeny index (ID1, ID2), kdyz chci delat join podle ID1.

V mysql záleží na pořadí. K práci nad id1 se dá ten index použít, k id2 bez id1 ne.

Firebird ho v úvahu bere, ale myslím, že ve starších verzích (které snad už nikdo rozumný nepoužívá :o)) byly nějaké háčky - máte-li podezření, vypište si plán dotazu. Jinde nevím, ale u PostgreSQL bych se divil, kdyby to neuměl.

Postgres ho vezme take.

Já to věděl! ;-)

Priklady jsou to krasne, ale ne pro vsechny DB, napriklad informix asi tuto cast bohuzel nezkousne.

JOIN (SELECT zam_id, sum(pocet) AS pocet
FROM PracovniNeschopnosti
GROUP BY zam_id) s


Dan

http://informix-technology.blogspot.com/2007/06/cheetah-spot-by-spot-derived-tables-in.html

Není problém GROUP BY v derivované tabulce, že na derivované tabulce neexistuje index a tak je pak spojení mnohem pomalejší než co se ušetřilo na GROUP BY?

To záleží na okolnostech. Pokud bude mít derivovaná tabulka do 1000 záznamů, tak index nehraje roli (taky dost často končí select v derivované tabulce LIMITem). Pri vetsim poctu uz je na zvazeni, co se vyplati. Na to aby se chytil index na GROUP BY tak musi byt vsechny sloupce ve slozenem indexu, coz namena minimalne jeden slozeny index navic. Nebo select do docasne tabulky. Tu oindexovat a pak provest spojeni. V mem prikladu pokud mam mene nez 1000 oddeleni, pak derevovana tabulka nevrati vic nez 1000 radku. Jinak, derivovanou tabulku pouziji, kdyz mi diky ni dojde k vyznamne redukci poctu radek tabulek, ktere vstupuji do JOINu.

A jeste se doplnim. Zalezi na enginu. Je rozdil mezi MySQL a Postgresem. V MySQL se nijak zvlast nedoporucuje pouzivat derivovane tabulky. Presto jsem tam tuto techniku uspesne pouzil. Ale jednalo se o denormalizovane (siroke) tabulky cca 30-40 sloupcu), takze redukce objemu dat pomoci derivovane tabulky byla docela vyrazna.

Tak nějak jsem si to myslel...jen že je třeba s vnořenými dotazy zacházet opatrně

Rozdil v rychlosti pri pouziti (+)= nebo OUTER JOIN muze nastat, na Oracle totiz novejsi varianta zapisu neni podporovana ve starem Optimizeru, takze pri pouziti klicoveho slova JOIN se optimizer prepne z pravdiloveho (RBO) na nakladovy (CBO) a jestli nejsou prirpavene dostatecne rpesne udaje pro vypocet nakladu, tak muze byt vysledkem neoptimalni provedeni dotazu.
Ale jde vlastne jen o problem se zastaralou a jiz prilis nepodporovanou veci - pravidlovym optimizerem.

Pouze pro upřesnění: přepis z ANSI normy na Oracle propriet-format nevede na změnu optimizer mod a nemá valný vliv na cost (testováno na 10gR2). Pokud je nastaven OPTIMIZER_MODE na CHOOSE, potom k omezení na RULE vedou jen specifické kombinace SQL dotazů (našel bych seznam, jinak AskTom). Co se týče přípravy statistik, naštěstí je CBO Oracle dost chytrý a pokud nemá žádné statistiky může použít dynamic sampling (default 32 bloků dat). Pokud je DADA jako ANOANO, tak smůla, jinak ženskou, která rozumí Oracle to bych chtěl potkat (něco co se jen tak nevidí). P.S. mám dost kolegů co zatuhli na úrovni 8i :)
Pro detaily doporučuji (Oracle® Performance Tuning for 10gR2 Second Edition --Gavin Powell, pg. 168)

My jsme jednou na Oraclu (9i) narazili na to, že dotazy s vnorenymi dotazy obsahujicimi linky do jinych databazi to pri vyuziti JOINove syntaxe vyhodnocovalo velmi neefektivne (select bezel i hodiny aby pak spadla na rollback segment too small) a i hinty to ignorovalo. Mistni DBA nam poradili prevod do ,WHERE syntaxe (pri zachovani stejne logiky), coz vyrazne pomohlo a jeste se to pak dalo trochu urychlit pomoci hintu.

To je asi právě ten případ, kdy selhal planner postavený na statistikách, protože statistiky neměl k dispozici. Což je spíše ta výjimka, která potvrzuje pravidlo.

S podobným problémem jsem se také setkal. Ke katastrofě došlo, když se primární CBO (9.2.0.6) snažil kamarádit se starou RBO (8.1.7.4). Bohužel v explain plan se pro tyto případy často objevuje REMOTE (serial_from_remote), cena uvedená ale může (a taky byla) uplný nesmysl. Ještě lepší to je u heterogenního linku např. do MSSQL nebo jinam. (cena/počet řádků/množství dat - nic z toho se nedá stanovit)

diky za nej. Jeste by se hodil clanek o spravnem pouzivani indexu a jinych optimalizacnich technikach, protoze to je rozvnez duleza vec jinak takova drobnost: v tomto priklade:

Zamestanci(id, oddeleni_id, jmeno, prijmeni, mzda)
Oddeleni(id, nazev) 

-- složený predikát
SELECT jmeno, prijmeni, mzda, nazev
   FROM Zamestnanci z
        JOIN (SELECT oddeleni_id, max(mzda) AS max_mzda
                 FROM Zemestnanci
                GROUP BY oddeleni_id) s
        ON z.oddeleni_id = s.oddeleni_id AND z.mzda = s.max_mzda
        JOIN
        Oddeleni o
        ON o.id = z.oddeleni_id;

podle me ta druha podminka v tom prvnim joinu ('...AND z.mzda = s.max_mzda ...') uz nemusi byt, ale mozna se mylim, priklad jsme nezkousel jinak kazdemu, kdo chce poradne proniknout do taju SQL bych rozhodne doporucoval knihu Introduction to SQL. Sice je dost rozsahla, ale fakt stoji za to, fucked fakt

Ta podmínka tam být musí, protože pouze jedna není (jakákoliv) není v rámci této úlohy jednoznačná. Zaměstnanci, které chci vybrat, mají nejvyšší mzdu v rámci oddělení - tudíž jsou potřeba dvě kritéria (mzda, a oddělení). Pokud by tam bylo pouze oddělení, tak mi to vypíše všechny zaměstnance, pokud dám pouze mzdu, tak to zhavaruje v případě, že sekretářka v administrativě má 10K (nad ní je ovšem ředitel s 20K), a hlavní inženýr z vývoje má 10K.

tak jsem se holt chytil:) je to tak, ted jsem si dal tu praci, abych se presvedcil. Kazdopadne dekuji za opravu. Me je totiz mnohem blizsi a pochopitelnejsi zapis (bez nazvu oddeleni)

SELECT jmeno, prijmeni from Zamestnanci
WHERE (oddeleni_id, mzda) in 
    (SELECT oddeleni_id, max(mzda) AS max_mzda
    FROM Zamestnanci
    GROUP BY oddeleni_id)

Bez te druhe podminky slouzi sice 'oddeleni_id' k propojeni obou tabulek ('z' a 's'; coz jsem si myslel, ze staci, kdyz v 's' se vybira max(mzda)), coz ovsem nebrani mysql v tom, vypsat vsechny zamestnance ('s' obsahuje vsechna 'oddeleni_id'; podminka rovnosti plati pro vsechny zamestnance), takze je opravdu nutna ta druha podminka. Fucked ze jo

Tohle je v každé databázi jiné. V Sybase based databází (včetně MySQL) se používá dočasná tabulka. Firebird má k tomu příkaz SUSPEND, která do výstupu přidá kopii OUT proměnných. V PostgreSQL jsou SRF funkce a RETURN NEXT. v PostgreSQL taková užitečná funkce generující tabulku o jednom sloupci a n řádků obsahující vzestupou posloupnost, která se jmenuje generate_series. Její zdroják by byl (kdyby byl v plpgsql, je ale v C) následující:

CREATE OR REPLACE FUNCTION generate_series(start integer, konec integer)
RETURNS SETOF integer AS $$
BEGIN
  FOR i IN start .. konec LOOP
    RETURN NEXT i;
  END;
  RETURN;
END;
$$ LANGUAGE plpgsql; 

Proto je duležité nepsat jak dobytek :)). A držet se ověřeného: Císařovo císaři, papeži papežovo..

Totiz to Vase zadani neni jednoznacne. Budto chcete vsechny zamestnance nebo chcete ty, jejichz pracovni neschopnost presahla 10 hodin. Pouze v pripade, ze by vsichni zamestnanci byli nemocni dele nez 10 hodin, tak lze na ni odpovedet. Jinak ty Vase priklady jsou presne tou ukazkou proc striktne pouzivat JOIN ON, ale korektne zapsany (nikoliv s Vasi zamernou chybou). Pak muzete bezpecne menit INNER JOIN na OUTER JOIN a nedockate se prekvapeni. Na neco podobneho jsem narazil v manualu k 7 MSSQL, kde ukazovali vyhody JOINU vuci klasickemu spojeni vyctem v FROM.

Pri programovani se musi davat pozor na detaily. To je samozrejmost. Utece Vam carka a padaji rakety. To, co tu navrhujete patri spis do firemniho now-how. Clanek byl urcen hlavne pro zacatecniky. Dalsi priklady by text jeste vic rozmelnily. Samozrejme, ze takhle se casto chybuje (copy/paste chyby). SQL je neskutecne variabilni i co se tyce chyb, ktere se daji udelat. Ale ja se setkavam s tim, ze programatori s nekolikaletou praxi netusi v cem je rozdil mezi INNER a OUTER JOINEM. To bylo hlavni motto clanku.

Doufam, ze tam nikde neni ze NOT IN a NOT EXIST jsou stejne. To, ze pomoci nich mohu napsat variace jednoho dotazu je uz neco jineho. A vsimnete si, prikaz s NOT IN vypada jinak nez s NOT EXISTS. Dale je tam poznamka, ze EXISTS vede ke korelovanemu dotazu, ktery je zpravidla ten nejpomalejsi.

Vasim kolegum doporucte precist si Joe Celka. Jsou to pomerne utle knizky, byt v anglictine, a myslim si, ze je tam to, co by Vas zajimalo.

Ta čárka je urban legend... :-)))

Pokud bych to mirne preformuloval. Chci zaznamy vsech zamestnancu, a jejich pracovni neschopnosti, s tim, ze u zamestnancu, kteri maji p.n. mene nez 10h zobraz nulu. Je to ono?

SELECT jmeno, prijmeni, CASE 
                            WHEN pocet IS NULL THEN 0
                            WHEN pocet <= 10 THEN 0
                            ELSE pocet END
   FROM Zamestnanci z
        LEFT JOIN
        PracovniNeschopnosti p
        ON z.id = p.zam_id;

Pokial mal clanok sluzit ku objasneniu rozdielov medzi LEFT / RIGHT / INNER / OUTER join, tak rozhodne chybaju vysledky uvedenych prikladov. Autor zrejme predpokladal citatelovu zrucnost a predstavivost (kde budu NULLy, kedy sa ktory riadok zaradi do vysledku..). Avsak takyto citatel zjavne davno vie, ako dane JOINy funguju.
Chcem tym povedat strucne - pre zaciatocnika prilis slabo vysvetlene, pre pokrocileho prilis malo informacii.

na zaklade aristotelovskej logiky si dovolim upozornit na chybu v clanku:
"Predikát je výraz, který po dosazení proměnných má hodnotu PRAVDA nebo NEPRAVDA (true nebo false)"

aristoteles tvrdi, ze SÚD (úsudok) vzniká spojením SUBJEKTu a PREDIKATU - tieto 2 sa spajaju spojkou JE... teda nam vznikne "SUBJEKT JE PREDIKAT" co tvori SÚD (úsudok)...

no a aristoteles tvrdi, ze o samotnom subjekte, ani o predikate nemozno tvrdit, ci je pravda alebo nepravda - iba o samotnom súde (usudku) mozeme daco taketo tvrdit ...


napr. Subjekt = Sokrates (spajaci vyraz JE) Predikat = clovek ==> Súd = "Sokrates je človek"

o samotnom Sokrates, alebo clovek nemozeme povedat, aku maju pravdivostnu hodnotu, preto je veta v uvode clanku chybna ...

len tolko som chcel - filozofiu neznasam a som prirodovedne zalozeny ... ;-)