To už jsou pak klasický cargo kulty. Optimalizace poddotazů, joinů je ve všech slušnějších databázích dneska z 80% stejná. Liší se kalkulace statistik a tudíž v některých případech některé dotazy jsou na jedné db rychlejší a na jiné pomalejší. Ve 20 procentech jsou rozdíly, ale to jsou dneska spíš obskurní věci, které se dají moderním SQL udělat jinak a rychleji. Je pravda, že MSSQL má agresivnější optimalizace korelovaných poddotazů obsahujících agregace - ale zase, kvůli tomu, má pomalejší planner. Hitne to malé procento dotazů. U Postgresu 90% lidí neví o parametrech JOIN_COLLAPSE_LIMIT a FROM_COLLAPSE_LIMIT, kterými se tato optimalizace řídí - a pak jsou překvapeni.
Tazatel by měl říct co chce umět. Tvoje odpověď směřuje k tomu, že db považuješ jako relační uložiště dat pro eshop či podobnou aplikaci, tam se ten provoz tolik opravdu neliší, já naopak vidím SQL jako jazyk pro analýzu/zpracování/reporting terabajtů dat v tisících tabulkách nad databázovým clusterem, kdy člověk několik měsíců píše sql dotazy, aby splnil jediný úkol.
Na trhu ve velkém chybí přesně tihle lidé, analytici (ať už byznys, BI, sales či jiní) s dobrou znalostí databáze a SQL jazyka.
V praxi jsem se snad nepotkal s programátorem, pro kterého by byl velký problém se naučit SQL v potřebné hloubce za pár týdnů/měsíců při běžném plnění úkolů. Pokud si tazatel chce jen k programování rozšířit znalosti, aby uměl napsat i nějaký "join" v SQL, asi mu stačí jakýkoliv manuál, knížka, kurz. Pokud naopak chce být tím SQL pánem na full time, zabere mu to dva roky studováním a učením se konkrétní databáze a jejich zákoutí.
Zobrazit příspěvky
