Vlákno názorů k článku [ ( LEFT|RIGHT [ OUTER ])| INNER ] JOIN v SQL od Radim Kolář - Clovek zvladne SQL az kdyz pochopi: 0. jak kodovat...
-
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. -
Rejpal (neregistrovaný)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. :-) -
Rejpal (neregistrovaný)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)
-
anonymníMáte pravdu, není to potřeba pro psaní SQL. Nad datovým skladem nebo vysoce kunkurentním OLTP to nutné je. Dříve jsem si myslel, že to není nutné, než jsem si přečetl a začal používat některé přístupy z:
--Cost Based Oracle (Jonathan Lewis)
--Effective Oracle by Design (Thomas Kyte)
--Relational database Index Design and the Optimizers (Tapio Lahdenmaki, Michael Leach).
Málokdo totiž ví jaké a jak jsou transakce a úrovně lock/latches realizovány nad jednotlivými DB. Skoro nikdo už není schopen říci co znamenají čísla v explain (ne co číslo znamená, ale proč tam je a co s tím udělat). Bohužel pro ladění je toto nezbytné. -
Rejpal (neregistrovaný)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é... ;)
-
Rejpal (neregistrovaný)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. :-)
-
wormsik (neregistrovaný)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. -
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.
-
anonymníNemůžete přeci tvrdit, že existuje cosi jako "standardní" implementace SQl, která všude funguje stejně dobře a výkonně. A bez znalosti optimalizátoru v té které implementaci nemůžete ÚMYSLNĚ napsat dobré statementy a už těžko můžete pomýšlet na nějakou optimalizaci pomocí indexů, pořadí klauzulí či použití hintů.
-
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.
-
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! -
lol (neregistrovaný)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. -
okbob (neregistrovaný)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. -
Rejpal (neregistrovaný)
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... -
Miloš (neregistrovaný)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, -
anonymníJa vidim problem v zlych navykoch ludi, ktori takto mozu pracovat. Prilisna volnost a nedoslednost sice mozno 'usetri' nejaky cas na vyvoji, no potom dava zabrat prevadzke.
Pripomina mi to klasicku debatu: "Preco Oracle nedovoli ulozit empty string, ked MSSQL s tym problem nema?"
Ano je to tak (aspon v starsich verziach urcite), a to len preto, ze v Oracle presne videli partiu web developerov, co kopiruju svoje textboxy priamo do DB a potom ich nadavanie a volanie na hotline, preco tie indexoy nad tym stlpcom nie a nie zabrat!
Ludia co prisli na projekt za 3 dni vedeli rozdiel medzi NULL a hodnotou a za 5 dni sa uz ani nepytali preco... Tento navyk im ostane dozivotne len preto, ze niekto nedovoli cokolvek a kedykolvek. -
anonymníOK pojdme si tu odlisit ruzne urovne "databazoveho psani".
1) cista amaterstina, kluk si precte Koska (nebo co ted leti) a napise si na LAMP vlastni webove forum/obchod/chat
2) vyssi uroven parta kluku 1) si za prachy z brigady zalozi firmu a ziska nejake zkusenosti, mabizi malym firmam pekne weby, obcas dela i neco cemu by se dalo rikat informacni system na miru
...
X) banka s mnoha tisici klientu provozuje v heterogennim prostredi plnem transakci mnoho aplikaci vcetne DWH komunikujicim s ruznymi back-endy a jejich databazemi (coz je samo o sobe opet mnoho ruznych urovni)
A) lehce genialni programator si ve vyzkumaku/fakulte/skole zejmena pro sve potreby za penize z grantu/od skoly/sponzora/dodavatele db hraje s ruznymi databazemi
Kazda z techto mnoha urovni ma jine predpoklady a zrejme vyuzije jinou databazi. -
anonymníAle ucit se databaze na MySQL je jako ucit se objektove programovat v PHP nebo javascriptu (a nejhorsi je, ze to casto jde ruku v ruce).
MySQL spis lidi v oblasti db zkazi a vtiskne jim spatne navyky.
Vy to pri vyuce nepozorujete? Ptate se studentu s cim prisli do styku, co s tim delali a sledujete potom nejakou korelaci? :) -
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. -
anonymníNo někde programátor začít musí - bez profesionálních zkušeností to co jste uvedl nemá šanci zvládnout. Pokud toto považujete za základní znalosti, abyste někoho přijal, tak jistě nabízíte odpovídající ohodnocení tzn. 60tis+. Pokud nabízíte méně, tak zřejmě hledáte pouze zájemce, kteří svou prací budou přispívat na vaší podnikatelskou charitu.
-
Martin Sedláček (neregistrovaný)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. -
Miloš (neregistrovaný)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. -
J (neregistrovaný)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).
-
wormsik (neregistrovaný)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. -
Miloš (neregistrovaný)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á. -
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. -
Petr (neregistrovaný)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. -
Martin Soukup (neregistrovaný)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.
