Vlákno názorů k článku Markus Winand: SQL Performance Explained od Adam - Takže celý článek je vlastně jenom reklama. Žádný...
-
ToC (neregistrovaný)
Nemyslím si, že jde o reklamu.
Četl jsem zde na Rootu s chutí několik autorových článků a věřím tomu, že problematice rozumí.
Naopak nevěřím tomu, že by měl zájem dělat reklamu zde nějaké publikaci. Proto děkuji za krátkou recenzi publikace a půjdu se zeptat zaměstnavatele, jestli bychom ji nemohli koupit do knihovny ;-) -
Primárně je to moje doporučení (pod které se mohu podepsat) přečíst si tuto knihu - a věřte mi, že jsem nedostal od Markuse ani halíř, a předpokládám, že iinfo na tom trhe zrovna takovou částku.
Přijde mi hrozně hloupé, že programátoři neustále opakují jednoduché chyby, které nedokáží jednoduše opravit (jelikož netuší, v čem je problém) a tak si hrozně komplikují život. A kolikrát ho komplikují i ostatním. Není to jenom moje zdejší zkušenost - zrovna tak to je i v Rakousku a jinde, kde Markus pracoval.
-
Ray (neregistrovaný)
Mne osobne to prislo fajn, protoze po techto vecech nekoukam. Jsem odkazan na to, ze kdyz nekdo ze sveho oboru narazi na neco zajimaveho, upozorni na to.
Spise by mne zajimalo, jesli ta uroven konci na podobnem "prikladu" (coz je opravdu "o nicem" a vychazi to jen z logiky veci) nebo jsou tam reseny veci, ktery uz nejsou vubec zrejmy (ruzny joiny, poradi vnorenych selektu, ....). A jestli to ma vlastne zas takovej prinos, vzhledem k tomu, ze si to planer stejne prekope "jak se mu libi".
Jestli bych se mohl Pavla na neco zeptat, jak by otazka znela: je knizka prinosem oproti pouziti "query plan" na postgresu (jinou DB osobne nepouzivam) ? Jesli ano o kolik :) Pac potom by za to asi stala. Papir je papir (:
Dekujemes
R.
-
Odpovím oklikou - většina problémů s výkonem je způsobená špatným zápisem podmínek, díky kterému si to planner nemůže překopat - a výsledkem je pomalý dotaz. Markus si postupně staví prostor, pro to, aby mohl tyto antipaterny vysvětlit - a aby čtenář prozřel - nestačí jenom vědět, co nedělat - důležité, je vědět, proč to nedělat. Tomu je věnována víc než polovina knihy.
Samotného popis optimalizace a interních mechanismů v DB tam moc není - alespoň z mého pohledu. Primární cílovou skupinou jsou aplikační vývojáři, kteří o db netuší vůbec nic a nevědí, co dělají - případně vývojáři, kteří o db něco vědí, ale kteří si chtějí ověřit svoje znalosti a svoje pozorování.
Není to o tom, že by se člověk dozvěděl víc nebo něco jiného než EXPLAIN query. Je to i tom, aby člověk přemýšlel, jestli to co dělá, dělá chytře a správně. Můžete mít dotaz, kde Vám EXPLAIN potvrdí, že všude jsou indexy, a přesto to může být špatně použitý dotaz.
Já osobně jsem se z této knihy o pg nedozvěděl nic nového, ale připomenuj jsem si pár základních antipaternů a jejich korektní řešení. Tohle není knížka, která by měla sedět v knihovně a prášit se na ní - každý vývojář by si ji měl přečíst pravidelně při nástupu do práce, a pak pravidelně prolistovat každý rok (cca 20 min), aby si připomněl jestli nedělá nějakou bejkárnu.
-
Přesně tak. Měl jsem v plánu recenzi pro LE, ale předběhl jsi mě. :-)
Souhlasím se vším, co je napsáno. Knihu jsem si koupil hned po Markově přednášce na P2D2 ne snad proto, že bych z té přednášky něco nevěděl a bylo to pro mě zcela nové, ale hlavně proto, abych si připomenul, ja se věcí mají (a hlavně nemají) skládat dohromady.
Knihu bych skutečně doporučil každému, kdo píše dotazy (což já mimochodem nejsem, já jsem administrátor db serverů, ale i tak si vždy rád přečtu o tom, co se v tom stroji děje uvnitř a jak to dělat lépe), měl by ji mít, alespoň nějaký čas na pracovním stole.
Když už pro nic jiného, tak jen pro přílohu o čtení prováděcího plánu. Spousta lidí píšící dotazy o plánu neví a i příkaz explain je pro ně novinkou (natož, aby plán uměli číst). Takže za mě, když už nic jiného, tak tato kapitolka by měla být povinná :-)
-
Karel (neregistrovaný)
Několik let jsem se víceméně živil optimalizací dotazů a reportů pro databázi Oracle. Prakticky cokoliv se dalo s pomocí indexů a vhodně zapsaných podmínek zrychlit. Obvykle se dařilo report, co běžel hodinu, zkrátit na několik desítek sekund. Ne proto, že bychom byli nějací úžasní mistři světa, ale proto, že autor původního kódu byl trouba.
Tou nejtriviálnější a bohužel i nejčastější chybou jsou neúplné dotazy.
Příklad:
Máme tabulku T1, klíč je A.
Máme tabulku T2, klíč je složený A a B.
Bohužel se pak běžně potkáte s dotazem:SELECT ..
FROM T1, T2
WHERE T1.A = T2.A
AND T1.A = 'a'
AND T2.B = 'b'Lidem, co tohle dokáží napsat, nepomůže ani svěcená voda. Přepsání do syntaxe INNER JOIN to může zatemnit, ale na výsledku nic nezmění. Do tabulky T2 se to prostě celým indexem nekoukne ani za zlaté prase. A přitom jsou hned tři způsoby jak to zlepšit. Který je nejvhodnější už závisí na konkrétních datech a je to potřeba zkusit. Konkrétně:
1. Změnit " AND T1.A = 'a' " na " AND T2.A = 'a' "
2. Přidat podmínku " AND T2.A = 'a' "
3. Tabulku T1 do joinu vůbec nedat a data z ní do SELECT vytaháme pomocí vnořeného selectu. Tedy něco jako:SELECT T2.*, (select x from T1 where t1.A = t2.A)
FROM T2
WHERE T2.A = 'a'
AND T2.B = 'b'Jakkoliv tato třetí metoda vypadá prasácky, tak v případech, kdy potřebuji jen jeden údaj a tabulka T2 má o několik řádů více záznamů než tabulka T1, to dává zdaleka nejlepší výsledky. Pokud máte v tabulce T2 data a tabulka T1 je jen nějaký slovník přiřazující popis ke kódům, je toto kupodivu nejrychlejší řešení.
-
maras (neregistrovaný)
Generalizaci jsi to zabil, kdyz uz hlasas, mel by sis vybrat co a nepopirat same sebe. Neni pravda, ze by subquery byly vzdy rychlejsi, zalezi na optimizeru jak bude vysledny dotaz v pripade subquery interpretovat, muze se totiz lehce stat, ze to prevede na inner join...
Tudiz bych se s tim "tomu nepomuze ani svecena voda" mirnil;-) -
Karel (neregistrovaný)
Ano, skoro vždy to skončí inner joinem. Jen občas nějakou exotikou. Já nekritizoval inner joiny. Ono bez joinu to ani nejde.
Já upozorňoval na lidi, kteří joinují tabulku T2, která má složený klíč A a B tak, že A joinují na jednu tabulku a B joinují na jinou tabulku nebo konstantu. Co databáze udělá je dotaz na tabulku T2 přes klíč A. Následně, podle nálady, buď udělá znovu dotaz na tabulku T2, tentokrát přes sloupec B, který není zaindexovaný, a pak ty dva výsledky spojí průnikem, nebo, v tom lepším případě, vezme výsledky přes klíč A a dále to zůží dotazem přes B, tentokrát také bez indexu, protože tabulka index začínající B nemá. Neudělá to na jeden dotaz přes index A,B, protože podmínky A a B odkazují na různé zdroje. A právě ten druhý filtr přes B, které není zaindexované, je zabiják výkonu.
Kdyby se místo toho dal dotaz přes A i B ze stejné joinované tabulky nebo oba jako konstanta, pak se dotaz provede přes index A,B, což je nesrovnatelně lepší výsledek.
Prostě je to o tom, že nevhodně zadaná podmínka místo dotazu jednoho udělá dotazů na stejnou tabulku více, obvykle neindexované, a pak teprve výsledky spojuje do jednoho.
A ten inner select má tu výhodu, že databáze ví, co se snažím udělat. Nalinkuje to správně, dokonce i když udělám dvě podmínky na různé zdroje (viz výše), tak to naplánuje tak, aby dotaz byl jediný. A tím, že z mého FROM zmizela tabulka, mám o to méně práce. U dvou tabulek to není takový rozdíl, ale dostat se z 10 tabulek na 3 už za to stojí (obzvláště pokud mám problém s kardinalitou nebo null hodnotami). Ve výsledku z toho stejně bude zase 10 tabulek, ale já se opticky starám jen o 3 a ten zbytek je najoinován automaticky a obvykle efektivně.
Je to léty ověřená praxe. Včetně toho, že neplatí univerzálně. Bez Explain Plan se neobejdu a občas jsem velmi překvapen. Zatím se mi ale nestalo, aby optimalizace pro jednu verzi Oracle způsobovala ve vyšší verzi problémy. Vyšší verze někdy nabízí ještě lepší řešení, ale nestává se, že by něco dobře běžícího ve staré verzi v té nové mělo zásadní problém. Tedy pokud nezačnete používat Pragma, ale to je pak jiná pohádka. Začínal jsem na Oracle 7.
-
Spíše jsem jako "řešení" v takovém případě viděl přidání dalšího indexu na T2.B. Takže tam jsou potom indexy T1.A, T2.A B, T2.B. Což potom vede k nárůstu diskových nároků (zbytečně se 3x kopírují data sloupce B) a také zpomalení dalších operací. Málokoho napadne tam dát podmínku (vlastně duplicitní) ještě na T2.B (a o tomto i tak kniha je, místo dalšího indexu se zamyslet nad existujícími predikáty).
-
podlesh (neregistrovaný)
Kdepak, to neudělá vůbec nic. Doporučuji vyzkoušet, ověřit. Pokud v nějaké databázi tato "řešení" u tohoto dotazu skutečně udělají nějaký rozdíl, tak to chce vyměnit databázi.
Mimochodem: já jsem tento dotaz skutečně ověřil, na reálné db2 databázi. PK na T2 se samozřejmě použije.
-
Upřímně řečeno si to nemohu vyzkoušet, protože výše uvedný problém (neúplný dotaz na t1 a t2 se složeným klíčem) Psql vyřešil způsobem, který už tu uvedl Pavel Stěhule. Prostě si tam doplní ten "chybějící" predikát a jede se podle složeného indexu.
Ovšem jsem si jistý, že ono řešení "doplň index nad t2.b" jsem v praxi již několikrát viděl, ale nad db, kterou tu nemám nainstalovanou.
-
Jarda (neregistrovaný)
Vase vypraveni je vyborna ukazka, jak nesmyslna vlastne ta cela SQL technologie je. Jiste, rozsirilo se to a neni pred tim uniku, ale kdyz uz se mame zamyslet, tak proc ne hned nad tim, kolik hruzy uz ta cela sql na lidstvo uvalila :-)
Jiste je krasne, ze se zivite tim, ze ty nesmysly, ktere pouzivanim sql vznikaji castecne korigujete. Ale predstava autora knihy a i autora recenze, ze se ja, aplikacni vyvojar, budu pri vsi me praci jeste zabyvat optimalizaci dotazuu je opravdu smesna. Kdo chce koncovemu zakaznikovi predat kvalitni dilo, ten ma jiz plne bryle te zakaznicke problematiky a jednoduse potrebuje nastroj (black-box), ktery za nej 'uschovu' dat prevezme.
V praxi to nakonec vypada tak, ze na puli cesty zustanou smysluplne pozadavky zakaznika a misto toho se cele tymy 'databazovych' odborniku snazi privest reseni postavene na sql-technologii k jakz takz rozumnemu provozu.
-
> predstava autora knihy a i autora recenze, ze se ja, aplikacni vyvojar, budu pri vsi me praci jeste zabyvat optimalizaci dotazuu je opravdu smesna
No a kdo jiný by se tím měl zabývat? To se pak nemusíte zabývat třeba ani optimalizací kódu a algoritmů, i ten jazyk, který aplikační programátor používá, je jenom nástroj...
Ale čemu se vlastně divím, optimalizace hardwarem je stále běžnější.
-
Jaeda (neregistrovaný)
to s temi algoritmy je spatny priklad. Ja mam svou praci rozvrzenou a algoritmy a funkce a podsystemy tvori jeden komplex, ktery je jednou naprogramovan a odzkousen. Je _nezavisly_ na poctu dat a jejich vzajemnych vztazich. Kdybych se mel u kazdeho zakaznickeho projektu zabyvat temito zaklady, tak nebudu nikdy hotov.
-
Přijde na to z jaké strany se na to díváte. Mohu to vidět taky tak, jak je to úžasná technologie, která ač to používají vývojáři bez hlubších znalostí a proškolení, tak zvládá to co zvládá.
Praxe nebrzdí SQL a SQL databáze - ty jsou svými možnostmi několik let před vývojáři - možná i celou dekádu. Alespoň u čeho jsem byl, tak projekty ztroskotaly na pokusech o naroubování zákaznických požadavků do systémů, které daným požadavkům vůbec nevyhovovaly, leč které byly prodány a u kterých obchodník nasliboval modré z nebe. Takže tu máme systémy, které se kolikrát používají (nebo je snaha používat) k něčemu, k čemu nebyly určeny. A do toho ještě některé z těchto systémů jsou blbě naprogramovány - případně blbě portovány. SQL v tom hraje zanedbatelnou úlohu. Je to jenom jeden z dalších chybně používaných subsystémů - jelikož ale bývá tím posledním v řadě, tak se na něj svede vše, bo na něco, někoho se to svést musí. Nicméně, pokud by tam nebyla SQL relační databáze, a byla tam jiná db technologie, tak by to dopadlo zrovna tak.
-
Jarda (neregistrovaný)
no asi se neshodneme, ale ja si pamatuji, jak jste nekdy pred 10 lety v nejake diskuzi rikal, ze staci skoleni a kazdy se to sql muze naucit. No a ubehlo 10 let a je tu zase recenze knizky, ktery se zabyva tim samym jako tenkrat, totiz jak to udelat, aby ty systemy uspokojive fungovaly.
A skoleni nenabizite jen Vy. Delaji to po celem svete a porad stejny obrazek. I nadale, jak jsme se dovedeli dole, delame 'my prasata' ty registry vozidel chybne. Ze by to prece jen lezelo na te technologii? -
Pořád si myslím, že SQL je možné se naučit. Základy SQL - práce s relacemi - 1 den, čtení prováděcích plánů - optimalizace - další den. SQL není složité. Ty dva dny tomu ale hromada vývojářů nikdy nedala! Bastlí to metodou COPY/PASTE co kde najdou na webu. SQL je technologie - není to umělá inteligence (zatím).
-
belzebub (neregistrovaný)
Vy si asi myslite, ze kazdemu vyvojari je 30 let, a SQL se mel naucit pred 10 lety a nyni ho musi umet. Asi Vas to prekvapi, ale v kazde dobe existuji jak zkuseni, tak nezkuseni programatori.
Neprekvapuje Vas pak tedy i fakt, ze se ve skolach stale vyucuje cesky jazyk? Predpokladam, ze jste rozhorcen nad tim jak je ten cesky jazyk spatne navrzen, kdyz ho nestacilo ucit za premyslovcu..
A ted vazne: z meho hlediska jsou nejvetsim problemem programatori, kteri znaji perfektne jednu nebo dve technologie a odmitaji se ucit jakekoliv dalsi s odkazem na to, ze by mely fungovat "out of the box" a pokud je s nimi problem, tak za to muze technologie a nikoliv oni. Zkuste si predstavit sebe v dobe, kdy jste Vas "pracovni" jazyk (tipuji Java/C++) neznal. Take jste si stezoval, ze po vas nekdo chce abyste znal detaily toho jazyka, jak se v nem pracuje, jeho knihovny atd?
-
Jarda (neregistrovaný)
ten priklad s tim jazykem je problematicky, jako nakonec u vsech prikladu. Ale to bychom se nakonec bavili o tom jak vhodna ta analogie je.
SQL byla pred 15 lety v zacatcich (co se sirsiho rozsireni tyce) a tehdy bych chapal, ze neexistovali odbornici. Ale od te doby probehla mnozstvi skoleni, na vsech skolach od stredni nahoru se to vyucuje, kazda databaze to ma ve jmene atd.
A jak pise pan Stehule, za 2 dny je mozno se to naucit. Tomu verim a vim, ze po tech dvou dnech ti absolventi take ulohy resi. Ten problem je, ze za 14 uz nevedi nic - protoze to _neustale nepouzivaji_. Pan Stehule a ti ostatni, kteri resi podobnou problematiku denne, tem to prijde snadne, ale tak to neni. relacni algebra a vubec logicke mysleni v oblasti mnozin je nam lidem vzdalene a zdaleka ne prirozene. Zjistilo se to take nakonec v evropskem skolstvi, kdyz se v polovine 60 tych let zkouselo zavest mnozinovy pocet do zakladnich skol. Velice brzy s tim skoncili.
Vase reseni a i tech ostatnich je v tom, ze se _programatori_ nauci to SQL (dalsi technologii). Pan Stehule zcela spravne pripomina, ze ani ty dva dny nejsou lide ochotni venovat a radeji pouzivaji copy/paste a jini diskuteri hovori o lenosti programatoru. Kdyby se lide snazili, tak by recenzovane knihy nebyly potreba.
Vite, ja mam s takovou argumentaci problem. I komunismus (rika se) by fungoval, jen kdyby lide chteli. Ale technologie, ktera odvisi od dobre vule uzivatelu je podle me chybna.
-
Karel (neregistrovaný)
Ale takhle to v tomhle světě funguje. Vy jste špeditérská firma a pro zákazníka se snažíte dostat zboží z místa A na místo B. Bohužel se budete muset naučit řídit auto i dělat údržbu. Budete muset nastudovat legislativu a budete muset pokaždé dávat pozor při řízení auta na ulici. Bylo by fajn, kdyby se auto dalo koupit jako black box, kterému řeknete odkud kam a ono se postará o zbytek.
Řešením je najmout si na to někoho jiného. Ale vyberte si někoho, kdo umí řídit auto. A jeho poznámku "na té silnici je most, pod kterým nic vyššího než 2.8m neprojede" berte jak daný fakt a nezkoušejte s ním smlouvat nebo mu nařizovat, ať ten most zruší. Není to jeho most.
A teď zpátky k SQL. Je silné, je rychlé, je efektivní. Dělá přesně to co má a je v tom velmi dobré. Problém nastává jen ve chvíli, kdy ho používá někdo, kdo nemá ani tuchy o tom jak to použít, nebo se to použije na něco, na co to není. Osobně jsem už dvakrát použití SQL lidem vymlouval. Důraz kladu na QUERY. Opravdu chcete použít databázi na to, aby jste se na data dotazovali? Ne? Že jen chcete perzistentní data? Tak to jděte jinam, na to vám SQL databáze nebude fungovat nijak zvlášť dobře.
-
Jarda (neregistrovaný)
ani Vas priklad neni vhodny, ale ja ho poupravim. Jsem spediter a musim prepravovat zbozi autem. Ale ta auta nemaji volant, nybrz ridic udeluje autu prikazy ustne. A auto si ten slovni prikaz rozparzruje, udela si provadeci plan a zacne servomotrkama natacet kola a tak. Ale ty prikazy musi ridic zadavat spravne a kdyz neco rekne blbe, tak se muze stat, ze auto jede doleva misto doprava.
No a ted se to nastavi tak, ze existuji jen takova auta, ve skolach a na skolenich se lide uci jak ta auta 'ridit' a vubec si nedovedou predstavit, ze se drive tahalo za volant. Ale pres ta vsechna skoleni je porad mnozstvi lidi, ketri davaji tem autum spatne prikazy , auta jezdi pomalu a jinym smerem. No a tak to je cela desetileti a obcas se objevi knizka, ve ktere stoji, jak davat tem autum ty spravne prikazy. Jeji recenzi jsme si dnes precetli.
-
Jarda (neregistrovaný)
ja sam pouzivam jine nez SQL databaze a samozrejme ze je pouzivaji i jini. Fakt ovsem je (a dole to nekdo take napsal), z se dnes pouzivaji SQL databaze na kazdou volovinu a jako vyvojar jsem 'nucen' z ruznych duvodu je i v ruznych resenich nabizet (tedy alespon na oko). Ty duvody jsou z 90% ciste politicke, jen z 10% prinasi _SQL standard_ vyhody. (pracuji v oblasti software pro mensi firmy).
-
ale to je přece normální. Zůstanu u aut - někdo to má v krvi a jen tak pro zábavu najezdí tisíce km a baví ho to a nevidí v tom nic obtížného, někdo to v krvi nemá, ale díky okolnostem je dotlačený k tomu, že najezdí taky tisíce km, a vyjezdí se, a někdo to nemá v krvi a okolnosti ho nedotlačí, a pak jakákoliv jízda je pro něj utrpením. Zatím auta dělají, to co jim řeknete - SQL databáze dělají totéž - i když s tím nesouhlasíte - není to žádná magie.
-
j (neregistrovaný)
Pokud neznas SQL tak se neser do delani appek ktery to pouzivaj ... jak jednoduchy. Takovy prasata nakopat do rite. Zcela osobne sem zrychlil firemni ERP o stovky procent ... prave proto, ze ti dobitci co to vyrabej zjevne netusej, co je to index a k cemu je to dobry ... nemluve o tom, ze naprosto klido joinujou tabulky pres textovy pole ...
Zjevne podobny prase jako ty napsalo registr vozidel, ze?
-
JackieX (neregistrovaný)
> Do tabulky T2 se to prostě celým indexem nekoukne ani za zlaté prase.
Je fajn, ze sa SQL tlaci medzi vysokourovnove deklarativne jazyky, ostava uz len pisat sql parsery, tak aby platilo to, co sa v matematike uci na zakladnej skole niekde v druhej triede. IF a = b AND b = c THEN a = c. Bohuzial sa tu na roote najdu experti, co si na takto odflaknutych databazovych implementaciach postavili business model. Obdobne ako antivirus industry profituje z neochoty MS fixovat bugy.
-
PG naprosto bez problémů:
postgres=# explain analyze select * from t1, t2 where t1.a = t2.a and t1.a = 34381 and t2.b = 100; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------- Nested Loop (cost=0.85..16.90 rows=1 width=16) (actual time=0.066..0.071 rows=1 loops=1) -> Index Scan using t1_a_idx on t1 (cost=0.42..8.44 rows=1 width=8) (actual time=0.040..0.041 rows=1 loops=1) Index Cond: (a = 34381) -> Index Only Scan using t2_a_b_idx on t2 (cost=0.42..8.45 rows=1 width=8) (actual time=0.020..0.022 rows=1 loops=1) Index Cond: ((a = 34381) AND (b = 100)) Heap Fetches: 1 Total runtime: 0.164 ms (7 rows) -
podlesh (neregistrovaný)
A sakra, nestihl jsem to... takže doplním že DB2 samozřejmě dělá totéž. Klidně sem hodím výstup db2expln, ale je toho hodně.
Takže jestli se nějaká databáze chová jak píše Karel, tak je řešení ještě jednodušší než nám navrhnul: vyměnit ji za něco normálního funkčního.
Jsem ale (občas) optimista a předpokládám že se prostě jedná o špatný příklad, vytvořený na místě z hlavy. Klasika.
-
Není problém napsat parser - a určitě by by bylo možné vložit algebraický modul, který by dokázal převést výraz sales_day + 1 = CURRENT_DATE na sales_day = CURRENT_DATE - 1, jenomže potom už byste se nedostal k časům kolem 1ms pro vytvoření plánu, a dejme tomu kompletní dotaz do 10ms. Takže tvůrci db jaksi předpokládají minimální inteligenci a znalosti u programátorů.
-
Logik (neregistrovaný)
A nebyla by cesta udělat něco takového a aktivovat to např. u uložených procedur, kde se plány cachují?
Nicméně v podstatě souhlasím s tím, že "blbci" se nikdy nedá vyjít dostatečně vstříc a že stejskání "vývojářů", že se musí naučit to supertěžké PHP, takže po nich nikdo nemůže chtít, aby se ještě naučili základy SQL, jsou poněkud trapné...
-
Možné to je, ale to by výrazně zvýšilo množství kódu, který je třeba udržovat (s čím souvisí větší množství chyb), přičemž to jen pramálo souvisí s hlavním důvodem existence ACID relačních databází - poskytovat konzistentní pohledy na persistentně uložená data - takže není moc velká motivace to dělat.
Když to zjednoduším - stačí dodržovat jednoduché pravidlo zápisu predikátů
sloupec = c, případně sloupec BETWEEN a AND b a nemůžete nic pokazit, ale jakmile napíšete fce(x) = konstanta, nebo fce(x) = fce(y), kdy fce může být i výraz, tak to je problém (pokud nevíte přesně, co děláte). To bohatě stačí.
-
JackieX (neregistrovaný)
??? To je nejaka divna logika. Bavime sa o asymptotickych zlozitosti (Big-O-Notation) alebo o nejakych 10ms milisekundach co nehraju absolutne ziadnu rolu, pri predkompilovanych dotazoch (prepared statement) ulozenych v cache pamati?!?
Vasu odpoved zaradim niekam k vyhlaseniu istej firmy z roku 2006 "Bolo by mozne vylepsit parsovanie javascriptu ale to by ste sa nedostal k response casom 1ms, takze nic robit nebudeme".
-
Ale určitě, jednou až bude vše naprogramované, tak dojde i na optimalizace výrazů a integraci algebraických operací - a bude to marketingový trhák. Aktuálně ale žádná databáze (pokud vím) takovou optimalizaci nenabízí - kdysi v dávné historii nebylo dost paměti na kód, pak se nedostávalo CPU, dnes, kdy je obojího dostatek si myslím, že se nikomu nechce sahat do odladěného kódu jelikož trh je saturovaný a i výrazná změna kódu by negarantovala zisk - vývoj se z relačních OLTP SQL databází přesouvá do OLAP SQL databází, kde trh ještě generuje peníze a je možnost si rozebrat trh. Je možné, že budoucí OLAP databáze budou mít architekturou blíž k Prologu a podobným strojům a navíc charakter zátěže u OLAP databáze poskytuje dost času pro tyto optimalizace (navíc bez zátěže +/- 25 let starého kódu).
PREPARED STATEMENTs nejsou univerzální řešení. Velké množství dotazů se provede jenom jednou a pak Vám straší v cache, údržba velké cache má velkou režii a navíc plány mohou zastarávat, takže je potřeba jednou za čas je rebuildnout.
