aha, tak teď si myslím, že začínám chápat to nedorozumnění.
Takže, nejde o tu rychlost, jde jen a pouze o tu modularitu. Z hlediska modularity je assembler a C rovnocené řešení, protože mohu s oběma stejně dobře rozdělit problém na menší části. Jestliže ale začnu míchat imperativní jazyky s deklarativním dotazováním dat, nastane ten známý impedance missmatch a jeho výsledkem je, že mohu modularitu zapomenout.
Kdybych se pokusi dosáhnout modularitu za pomoci RDBMS prostředků (tedy s deklarativním SQL jazykem), tak pak bych do sebemnší funkce zapsal nějaký select-statement. Taková funkce by formálně splňovala ten information hiding princip, prakticky je to ale nepoužitelné. Taková funkce může bý samozřejmě použita jakkoliv - tedy v nějaké smyčce se 100 tisic voláni. A v tu chvíli je to pomalé, nepoužitelné a tím jsme u té rychlosti , která zdánlivě zapříčiní ten problém s tou modularitou - ve skutečnosti je to ta SQL.
Jasně, a to je přesně to, co byste neměl v SQL dělat - tam platí, co můžete udělat jednou hromadnou operací, tak byste měl udělat jednou hromadnou operací. Pokud byste chtěl zapouzdřit nějaké dotazy, tak od toho tu jsou pohledy. Modularita v SQL db pro přístup v databázi se nedá udělat na aplikační straně funkcemi.
Porušení tohoto pravidla vede k tomu, že uživatelé mají pocit, že relační db jsou pomalé - už od dob COBOLu - a v každé best practices k SQL db se to dočtete na prvním místě. Tak jak v COBOLu, v IMS budu muset psát jiným stylem (což mi ani nezbyde, protože tam mám jiné vyjadřovací možnosti), tak v SQL se zase píše jiným způsobem než v těchto databázích. To je opravdu diskuze, která se vede od dob COBOLu a pro to, abyste mohl efektivně s SQL pracovat, tak musíte pochopit, že existují hromadné operace, a pohledy. Pokud to pochopíte, tak ok, pokud ne, tak pak vlastně tu databázi používáte tím nejhorším možným způsobem.
A i když ji už používáte tím nejhorším možným způsobem - pokud se použijí prepared statements a máte indexy, tak i při tom ISAM přístupu se dostanete k časům pod 1ms, což si myslím, že na těch starých mašinách jste neměli. Jenomže, pokud čtu 1000 řádků po jednom, tak jsem možná na 100ms, možná na vteřině. Pokud to udělám hromadnou operací, tak jsem na 1-10ms. Samozřejmě záleží jestli ještě do toho mám síťový traffic nebo nemám. Mám zákazníka u kterého reporty trvají minuty, bo jsou napsány funkcionálně - což je to nejhorší, co může být. Když je napíšu čistě, tak trvají několik málo vteřin - protože optimalizátor dostane prostor k optimalizaci. Ale tohle je blbost těch programátorů, kteří ignorovali fakt, že už nedělají v ISAM db, ale v Oracle.
Každá technologie má něco, co musíte respektovat, a pokud to nechcete nebo neumíte, tak to nepoužívejte. Excel je super, ale když ho začnu ohýbat na databázi, tak je to zoufale pomalé. A opačně - multidimenzionální reporting se mi dobře udělá v Excelu a relační databázi je to oser.
Zobrazit příspěvky
. Vemte libovolný mainstream jazyk. Teď jsem školil lidi, co dělají erlang, a po nějaké době jsem měl z toho školení velice dobrý pocit. Nicméně erlang je a byl jazyk z vyšší vstupní bariérou, a ten jazyk dělají srdcaři. JS umožňuje prasit, ale umožňuje také napsat špičkové portabilní aplikace.
