Vlákno názorů k článku Zákys jménem flattening od honza - pane kolego, neni Vas clanek prave jeden z...
-
Predpokladam, ze databaze postavene na sitovem nebo hiearchickem modelu by timto neduhem netrpeli. Proste tam planer neexistuje, a tudiz nemuze mit ani problemy. Na druhou stranu relacni databaze jsou podstatne adaptabilnejsi a jednodussi oproti svym predchudkynim. K tomu jeste, pokud vim, ze data maji tento charakter, tak mohu svoji aplikaci vuci tomuto chovani obrnit. Skutecne jednoduse. Do tretice, jedna se o vyjmecne pripady. Cim castejsi by byly, tim lepe se bude planner chovat. A uplne posledni argument. Pokud bych to bral jako nevyhodu, pak je to problem jedne implementace relacniho modelu, nikoliv problem samotnych relacnich databazi.
Je to rozdil mezi proceduralnim a neproceduralnim programovanim. Pri proceduralnim pristupu zalezi vic na kvalite programatora. Pri neproceduralnim zas na kvalite implementace. Kdyby nebylo SQL, tak by jeste databaze programovalo par silencu hrozne draho a ostatni by si o nich vykladali, jaky ze to jsou borci. Diky SQL se staly databaze beznou zalezitosti. -
honza (neregistrovaný)[...]Predpokladam, ze databaze postavene na sitovem nebo hiearchickem modelu by timto neduhem netrpeli. Proste tam planer neexistuje, a tudiz nemuze mit ani problemy.[...]
100%
[...]Na druhou stranu relacni databaze jsou podstatne adaptabilnejsi a jednodussi oproti svym predchudkynim.[...]
hmm, ale my technici takove vety prenechavame politikum, protoze jsou pod nasi uroven, ne ...
[...] K tomu jeste, pokud vim, ze data maji tento charakter, tak mohu svoji aplikaci vuci tomuto chovani obrnit. Skutecne jednoduse. [...]
??
[..]Do tretice, jedna se o vyjmecne pripady. Cim castejsi by byly, tim lepe se bude planner chovat. A uplne posledni argument. Pokud bych to bral jako nevyhodu, pak je to problem jedne implementace relacniho modelu, nikoliv problem samotnych relacnich databazi.[...]
to ano, ale viz nize
[...]Je to rozdil mezi proceduralnim a neproceduralnim programovanim.[...]
neznam aplikaci (napr. nejaky informacni system), ktera by se obesla bez proceduralni slozky(src:vlastni zkusenosti :-))
[...]Pri proceduralnim pristupu zalezi vic na kvalite programatora.[...]
Na kvalite programatora zavisi vzdy, koeficient je podle "pesimistickych" odhadu
1:30 (src:Helmut Balzert), podle "optimistickych" 1:1000 (src:software factories). Chci rici, ze jestlize zacneme do cele problematiky tahat (programatorskou) kvalitu lidi, tak toho muzeme hned nechat, nebot rozptyl tech kvalit premlati radove vsechny ostatni rozdily.
[...]Pri neproceduralnim zas na kvalite implementace. Kdyby nebylo SQL, tak by jeste databaze programovalo par silencu hrozne draho a ostatni by si o nich vykladali, jaky ze to jsou borci. Diky SQL se staly databaze beznou zalezitosti. [...]
?? - databaze programuje prece i nadale par silencu a ostatni si o nich mysli ze jsou borci. Minite databazove aplikace?
Moje poznamka se netykala ani tak toho konkretniho problemu s analyzatorem, spise jsme chtel poukazat na to, jaky obrovsky aparat se kolem tohoto modelu vybudoval. Vas clanek je jednim z mnoha milionu, ktery se zabyva s nejakou castecnou problematikou.(src:internet,diskuze k databazim) A diskuze zde to take nadherne potvrzuje. Jeden je pro hinty, druhy je v postgresql nechce videt, treti uz s nimi pracoval, ale jen pod Oracle a nyni uz chybi, aby rekl ze to bylo ve verzi 9.1.x.7, rel.12 a ze v te verzi 10.0.1.3 rell.xxx je to zase trochu vylepsene s tim, ze zase zmenili ty subselecty ... apod.
To podstatne je, (bohuzel), ze den ma jen 24 hodin(src:ustav pro miry a vahy). A budto v tomto case bojuji s problemy, ktere mi pred nohy hodil nejaky model, nebo se venuji problemum zakazniku.(src:polemika :-)) -
Marek Jakub (neregistrovaný)Osobně jsem programoval mission critical "databázovou" aplikace ještě v MSDOSu v knihovně Btrieve, nebo jak se to jmenovalo, což byla souborová databáze. Veškeré řízení bylo procedurální včetné použití indexů. Nedokážete si představit, jaký to byl opruz a jak to bylo těžké. To co dnes řeším napsáním jednoho ad hoc dotazu během minuty, byla práce na několik hodin.
I první verze FOXky a jí podobných to řešila podobně, ale byly k dispozici dokonalejší nástroje pro práci s daty, nicméně podstatná ćást práce byla stejně procedurální. Joiny znala FOXka myslím až v nějaký pozdějśí verzi.
Relační databáze, resp. jejich implementace přinesli zjednodušení v řádu několika řádů. Standardizace SQL umožnila vznik mnoha nástrojů pro práci s daty. Dnes to považujeme za standard a proto pláčeme nad klacky, které nám implementace hážou pod nohy, ale věřte, že borci kteří tehdy DB aplikace psali byly tehdy asi takového kalibru, jako dnešní vývojáři nízkoúrovňoví céčkoví unixáři.
Jsem přesvědčen, že budoucnost bude z velké části neprocedurální, protože požadavky na rychlost vývoje a kvalitu kódu budou růst a kvalitních vývojářů bylo, je a bude málo. Dokonce mám pocit, že jich je pořád méně.
Vidím ty umělé inteligence, kterým řeknete, že chcete něco jíst a ony Vám podle Vašeho zdravotního stavu, nálady a nevím čeho nabídnou a uvaří nějakou dobrotu. :-).
Jestli nakonec vyhraje relační model, nebo hierarchický, či síťový je v zásadě jedno, protože budoucí vývojáři už ani nebudou vědět co to je. -
>>[...]Na druhou stranu relacni databaze jsou podstatne adaptabilnejsi a jednodussi oproti svym predchudkynim.[...]
> hmm, ale my technici takove vety prenechavame politikum, protoze jsou pod nasi uroven, ne ...
Když mám dobře zabezpečenou databázi, tak mohu pustit proškoleného uživatele s crystal reports (či jiným sw) do databáze, by si vytvářel reporty sám. Zpravidla nemusí mít ani znalost SQL (nicméně to není naškodu). Díky relačnímu modelu mohu celkem jednoduše vytvářet nové vazby (třeba virtuální). V jiných modelech už musím programovat. Někdo preferuje programování, někdo parametrizaci. Já, to je jasné, parametrizaci.
>> [...] K tomu jeste, pokud vim, ze data maji tento charakter, tak mohu svoji aplikaci vuci tomuto chovani obrnit. Skutecne jednoduse. [...]
> ??
Stačí mi jedna tabulka s počty výskytů. Tu stačí aktualizovat jednou za čas. Předřadím SELECT do této tabulky, a pak provedu čistý dotaz nebo dotaz s OFFSETEM.
[...]Je to rozdil mezi proceduralnim a neproceduralnim programovanim.[...]
neznam aplikaci (napr. nejaky informacni system), ktera by se obesla bez proceduralni slozky(src:vlastni zkusenosti :-))
já také ne. Nicméně pokud něco lze vyřešit neprocedurálně, preferuji neprocedurální přístup. Pro většinu neprogramátorů je výsledek čitelnější. Nemyslím si, že SQL je absolutně přenositelný, nicméně SQL dotaz zapsaný pro Oracle by měl dokázat přečíst i ten, kdo se učil SQL na Microsoftu. Neznám podobný standard, který by existoval pro nerelační databáze.
Netvrdím a tvrdit nikdy nebudu, že relační databáze se hodí na všechno (např. fulltext postavený pouze nad relačním modelem by byl značně neefektivní). Na druhou stranu, kdyby dost dobře nepokrývaly požadavky, tak by je nikdo nepoužíval 20 let. Sám pamatuji řadu vln, z poslední doby čistě OOP nebo čistě XML databáze. Kde jsou? Zato relační databáze se rozšiřují i tam, kde bych je nečekal (SQLite). Je to o.s., který se chová evolučně.
>> [...]Pri proceduralnim pristupu zalezi vic na kvalite programatora.[...]
> Na kvalite programatora zavisi vzdy, koeficient je podle "pesimistickych" odhadu
1:30 (src:Helmut Balzert), podle "optimistickych" 1:1000 (src:software factories). Chci rici, ze jestlize zacneme do cele problematiky tahat (programatorskou) kvalitu lidi, tak toho muzeme hned nechat, nebot rozptyl tech kvalit premlati radove vsechny ostatni rozdily.
SQL dokáže používat řada lidí, kteří v životě nepochopí cyklus. I bez SQL díky grafickým rozhraním relační databáze dokáží používat amatéři (někdy ke své škodě, někdy k užitku).
>> [...]Pri neproceduralnim zas na kvalite implementace. Kdyby nebylo SQL, tak by jeste databaze programovalo par silencu hrozne draho a ostatni by si o nich vykladali, jaky ze to jsou borci. Diky SQL se staly databaze beznou zalezitosti. [...]
> ?? - databaze programuje prece i nadale par silencu a ostatni si o nich mysli ze jsou borci. Minite databazove aplikace?
Kolik aplikací vyjma her není postaveno nad databázemi. A kolik z těch databází není relačních? Je mi znám fakt, že největší db světa Google není relační :-)
> Moje poznamka se netykala ani tak toho konkretniho problemu s analyzatorem, spise jsme chtel poukazat na to, jaky obrovsky aparat se kolem tohoto modelu vybudoval. Vas clanek je jednim z mnoha milionu, ktery se zabyva s nejakou castecnou problematikou.(src:internet,diskuze k databazim) A diskuze zde to take nadherne potvrzuje. Jeden je pro hinty, druhy je v postgresql nechce videt, treti uz s nimi pracoval, ale jen pod Oracle a nyni uz chybi, aby rekl ze to bylo ve verzi 9.1.x.7, rel.12 a ze v te verzi 10.0.1.3 rell.xxx je to zase trochu vylepsene s tim, ze zase zmenili ty subselecty ... apod.
Co je na tom zvláštního. Buďto začínám od nuly a napíší si aplikaci přesně podle mého gusta, nebo se smířím s určitou neefektivitou a používám knihovny. Mercedes má mnohem větší spotřebu než kolo. Potom, ten aparát se vyvíjí 20 let, za tu dobu se napsala hromada kódu, objevily se nové metody, je k dispozici silnější hw, takže co před 10 lety se dalo řešit teoreticky se teď dá řešit prakticky. Změnila se architektura, od zámků se přechází k MGA. Roztříštěnost to samozřejmě je. Každá firma vychází z jiného prostředí, má jinou filozofii, jiné cílové zákazníky, jiné požadavky, jiné cíle. Což je jenom důsledek, že tento model žije.
Kdyby předrelační modely měly tutéž životaschopnost, a věnovala se jim tolik pozornosti, tak produkty s touto filozofií budou stejně různorodé. To, že jsou na okraji zájmů má nějaký důvod.
> To podstatne je, (bohuzel), ze den ma jen 24 hodin(src:ustav pro miry a vahy). A budto v tomto case bojuji s problemy, ktere mi pred nohy hodil nejaky model, nebo se venuji problemum zakazniku.(src:polemika :-))
Naprosto souhlasím. A proto musím napřed technologii, kterou používám rozumět. Žádný sw. se nesmí znásilňovat, tj. používat hloupě na nevhodném místě, jelikož to jinak končí průserem. Řada problémů je zděděných. Pokud někdo přeportoval Cobolovskou aplikaci do SQL 1:1, a myslel si, že to bude fungovat, tak pravděpodobně všem dalším dost zkomplikoval život. Každou techologie chce svoje. Uvedu příklad. Celá generace programátorů vyrostla na FoxPro. V okažiku, kdy začali portovat svoje aplikace na SQL, měli hromadu problémů. Problém nebyl v SQL nebo ve FoxPro. Problém byl v lidech, kteří nepochopili ze začátku principy SQL. SQL učím a vím, že je mnohem obtížnější čit programátory než amatéry, kteří nic nevědí o procedurálním programování. -
JoHnY (neregistrovaný)Musim reagovat na vas uplne posledni odstavec. Mam potvrzeni z mnohem pozdejsi doby nez FoxPro(nastupil jsem na zastavce, kde foxko definitivne vyhodili z vlaku).
Uz nekolikrat se mi overilo, ze lide kteri jsou dobri programatori vetsinou relacni databaze prilis nemyluji. Dobre rozumi algoritmum ..., ale uvazovani v relacich je jim z nejakeho duvodu nepohodlne.
Programatori zacatecnici maji casto tendence pouzivat SQL databaze jako velke vicerozmerne pole a s daty se prat az na strane jazyka(take jsem tim trpel a ne malo). Uz jsem par zacatecniku vydesil tim, ze jsem jejich databazi naplnil "odpovidajicim" vzorkem o nekolika desitcha tisic zaznamu a potom jim ukazal spotrebu pameti a rychlost jejich mileho programu. Mam z toho vzdy skodolibou radost, asi z duvodu, ze jsem podobne kraviny delal taky. Zkratka casto maji pocit, ze vsechno musi naprogramovat, a pritom staci jen rict SQL serveru a ten udela drinu za ne, navic rychle a bez memory leaku nebo odpornyho osetrovani vyjimek :)
Nejsem zadny super programator(nejsem na to dostatecny blazen - C++ pozitivni prominou ;) ), ani neovladam nijak bravurne SQL, ale na tekuty chleba ke studiu to staci s prehledem :) -
honza (neregistrovaný)uf ...
nemohu se ubranit, ale nejak citim v odpovedich nejaky rozpor. Na jedne strane to bylo drive vsechno strasne obtizne a dnes je to otazka nekolika minut, ale ti lide, kteri by to meli delat tu nejak nejsou, SQL nechapou, musi byt horem dolem skoleni, nez se pusti po tom skoleni k databazi, tak ta musi byt dobre zajistena, rada jich pouziva databazi jako velke pole atd.
Nerikam to ustepacne, bohuzel jsme si ve firme take mysleli, ze aspon ty reporty si udelaji ti uzivatele sami, kdyz uz je tu ten standard. Chyby lavky, sef nakupu nas hnal okamzite az k vedeni, ze on a ani jeho podrizeni se nebudou nic ucit, oni jsou tu od nakupu. Znam samozrejme radu instituci (vesmes statnich), kde maji zamestnanci cas na hrani, ale u nasich zakazniku (vyrobni firmy) to nemohu pozorovat.
A budme uprimni, kdyby mel nekdo vedle sve prace pochopit, co se za db-navrhem skryva, tak muze jit z fleku delat toho analytika. A jak by to take mel pochopit, ve vasich prispevcich to stoji - ani lide z oboru to nechapou - ale co to je za model, ktery 1/2 lidi nechape?
Ptate se, proc je to rozsirene - inu myslim, ze se na tom da prave pekne vydelavat. Napr vy si privydelavate skolenim. Co by jste skolil u ISAMU? Rekl by jste, ze programator prske do nejakeho pole udaj, podle ktereho chce hledat (=WHERE) a ve smycce se pta(NEXT, PREV), jestli se mu to, co se naslo libi. Tim je cely model vysvetlen. To by jste si asi mnoho nevydelal.
Jeste jednou, souhlasim s tim, ze ti lide, kteri by to meli pouzivat tu NEJSOU. Ani tisice skoleni to nezmakla. Plna databazova-fora stupinich dotazu na primitivni selecty to potvrzuji. A to je jen jeden z duvodu, pros si myslim, ze je ten model katastrofa. -
okbob (neregistrovaný)> nemohu se ubranit, ale nejak citim v odpovedich nejaky rozpor. Na jedne strane to bylo drive vsechno strasne obtizne a dnes je to otazka nekolika minut, ale ti lide, kteri by to meli delat tu nejak nejsou, SQL nechapou, musi byt horem dolem skoleni, nez se pusti po tom skoleni k databazi, tak ta musi byt dobre zajistena, rada jich pouziva databazi jako velke pole atd.
Pokud nepochopite zaklady C nenapisete krome hello zadnou dalsi aplikaci (C povazuji za nejjednodussi jazyk). Proc se pouziv neefektivni java nebo C++, kterou se musim dele ucit. Protoze ve vysledku prinasi urcite pohodli.
> A budme uprimni, kdyby mel nekdo vedle sve prace pochopit, co se za db-navrhem skryva, tak muze jit z fleku delat toho analytika. A jak by to take mel pochopit, ve vasich prispevcich to stoji - ani lide z oboru to nechapou - ale co to je za model, ktery 1/2 lidi nechape?
Pokud programator nerozumi obsahu, tak jak to muze dopadnout? Problem neni v SQL.
> Ptate se, proc je to rozsirene - inu myslim, ze se na tom da prave pekne vydelavat. Napr vy si privydelavate skolenim. Co by jste skolil u ISAMU? Rekl by jste, ze programator prske do nejakeho pole udaj, podle ktereho chce hledat (=WHERE) a ve smycce se pta(NEXT, PREV), jestli se mu to, co se naslo libi. Tim je cely model vysvetlen. To by jste si asi mnoho nevydelal.
Vzpominam si na celkem draha skoleni Btree. FoxPro nas ucili cely jeden semestr. V accessu jsme prechazeli na SQL naprosto spontalne, protoze nam umoznovalo o dost citelnejsi zapis kodu. Nemohu souhlasit.
> Jeste jednou, souhlasim s tim, ze ti lide, kteri by to meli pouzivat tu NEJSOU. Ani tisice skoleni to nezmakla. Plna databazova-fora stupinich dotazu na primitivni selecty to potvrzuji. A to je jen jeden z duvodu, pros si myslim, ze je ten model katastrofa.
Nejsou ale budou. Stare generace vymrou, jako cobolisti, rplisti a jim podobni. Ta fora signalizuji neco jineh. Ze programatori jsou lina banda neochotna premyslet, kdyz maji po ruce google nebo konference. -
mys elf (neregistrovaný)>> Jeste jednou, souhlasim s tim, ze ti lide, kteri by to meli pouzivat tu NEJSOU. Ani tisice skoleni to nezmakla. Plna databazova-fora stupinich dotazu na primitivni selecty to potvrzuji. A to je jen jeden z duvodu, pros si myslim, ze je ten model katastrofa.
>Nejsou ale budou. Stare generace vymrou, jako cobolisti, rplisti a jim podobni. Ta fora signalizuji neco jineh. Ze programatori jsou lina banda neochotna premyslet, kdyz maji po ruce google nebo konference.
Myslím, že autor měl na mysli "pokročilé uživatele", tedy typické uživatele Excelu a ne programátory. Je fakt, že představa, že středoškolák před důchodem bude efektivně používat složitější SELECTy je dost odvážná, na druhou stranu mu lze díky SQL snadno ušít nástroj na míru, který mu dotaz sestaví z naklikaných parametrů (a pošle na server a zobrazí výsledky). -
honza (neregistrovaný)[...]na druhou stranu mu lze díky SQL snadno ušít nástroj na míru, který mu dotaz sestaví z naklikaných parametrů [...]
ta otazka softwaroveho inzenyrstvi zde je: KDO MU TO SESTAVI ???
- udela to pan Stehule ...(pojede do Tramtarie to nekomu sestavit)
- udela to kolega, ktery se tak dobre vyzna v te materializaci a nested loopech?
- udelate to vy ?
- udelam to ja ?
Ne, v 99% vsech pripadu se nebude dit vubec nic, protoze zde neni v patricnem okamziku ten, KTERY BY SESTAVIL. Ekonomicky je to nemozne. -
> Ne, v 99% vsech pripadu se nebude dit vubec nic, protoze zde neni v patricnem okamziku ten, KTERY BY SESTAVIL. Ekonomicky je to nemozne.
Ale je to mozne. Je rozdil jestli u nekoho programuji, nebo sestavuji SQL. A skutecne, at tomu verite nebo ne, lze neprogramatory naucit SQL. To, ze nevidi do vnitrnosti a nesestavi SQL prikaz absolutne efektivne, je v 99% jedno. Pokud jsou nastavene rozumne limity, tak nemaji co pokazit. Pokud narazi, tak si nekoho najdou, kdo jim pomuze. -
Makovec (neregistrovaný)souhlasím s Vámi. Pracoval jsem před lety na balíku účetního a personalistického software pro velké a střední podniky, a uživatelé (tj. účetní a personalisté) si měli možnost sami vytvářet a upravovat sestavy založené na SQL, a po zaškolení to vesměs dokázali (jó komplexní věci a nebo optimalizaci dotazu který byl opravdu příliš pomalý si dokoupili - a nebo jim pomohli jejich IT všeumělové - ale to bylo odhaduji pár procent případů).
Dokonce byla (je) tato možnost vítanou součástí a pro některé důležitou konkurenční výhodou uvedeného software. -
bbubla (neregistrovaný)"Nerikam to ustepacne, bohuzel jsme si ve firme take mysleli, ze aspon ty reporty si udelaji ti uzivatele sami, kdyz uz je tu ten standard. Chyby lavky, sef nakupu nas hnal okamzite az k vedeni, ze on a ani jeho podrizeni se nebudou nic ucit, oni jsou tu od nakupu. Znam samozrejme radu instituci (vesmes statnich), kde maji zamestnanci cas na hrani, ale u nasich zakazniku (vyrobni firmy) to nemohu pozorovat."
Jsem uživtelem jedné databáze, kterou tvoří jeden čaroděj již sedmým rokem. Je stejného názoru jako byl tento.
Skladník, dispečerka nebo obchodník s železe si musí vydělat nejen na sebe, svou firmu. Nemohou tedy bádat nad tajemstvím SQL. Na to má najmuto a platí toho čaroděje, který si myslí, že si to uživatel přece dodělá.
Vaši uživatelé jsou placeni za jinou práci a musí uživit i Vás. Mylete na to.
Bbubbla, trochu zběhlejší BFU -
bbubla (neregistrovaný)"Nerikam to ustepacne, bohuzel jsme si ve firme take mysleli, ze aspon ty reporty si udelaji ti uzivatele sami, kdyz uz je tu ten standard. Chyby lavky, sef nakupu nas hnal okamzite az k vedeni, ze on a ani jeho podrizeni se nebudou nic ucit, oni jsou tu od nakupu. Znam samozrejme radu instituci (vesmes statnich), kde maji zamestnanci cas na hrani, ale u nasich zakazniku (vyrobni firmy) to nemohu pozorovat."
Jsem uživtelem jedné databáze, kterou tvoří jeden čaroděj již sedmým rokem. Je stejného názoru jako byl tento.
Skladník, dispečerka nebo obchodník s železe si musí vydělat nejen na sebe, svou firmu. Nemohou tedy bádat nad tajemstvím SQL. Na to má najmuto a platí toho čaroděje, který si myslí, že si to uživatel přece dodělá.
Vaši uživatelé jsou placeni za jinou práci a musí uživit i Vás. Mylete na to.
Bbubbla, trochu zběhlejší BFU -
mka (neregistrovaný)[...]Na kvalite programatora zavisi vzdy, koeficient je podle "pesimistickych" odhadu
1:30 (src:Helmut Balzert), podle "optimistickych" 1:1000 (src:software factories). Chci rici, ze jestlize zacneme do cele problematiky tahat (programatorskou) kvalitu lidi, tak toho muzeme hned nechat, nebot rozptyl tech kvalit premlati radove vsechny ostatni rozdily.[...]
Prave naopak, je potreba pocitat s tim, ze dobrych programatoru je hodne malo a tezko se hledaji. Takze kdyz pouziju relacni databazi (ktera je odladena, otestovana a praxi proverena), tak vim, ze vyuziju praci a talent tech hodne dobrych programatoru, kteri ji napsali. Naopak, kdyz si to budu programovat sam, nebo to nejakemu programatorovi zadam, bude to stat vic prace a navic dost riskuju, ze to dopadne hur. A pokud uz bych byl tak dobry (nebo mel tak dobreho programatora), ktery by to byl schopen napsat lepe, je zase mrhani talentu programovat neco, co jde vyresit neproceduralne nekolika SQL dotazy (byt treba z hlediska naroku na strojoveho cas o neco mene efektivne). -
mys elf (neregistrovaný)Nejde jenom o tohle. Když budu třeba mít rozumný E-R model databáze, tak i méně chápavému programátorovi poměrně snadno dojde, jak jsou data v systému uspořádaná. A kolem relačního modelu existuje vcelku dost propracovaná teorie (normální formy apod.) a vývoj jde stejně cestou používání standardních komponent, metodologií, formálních specifikací (UML, návrhové vzory apod.). Jenom tak se dají větší projekty držet pohromadě s rozumným úsilím. Na genialitu superprogramátorů, kteří umějí opravovat operační systém v hexakódu se spoléhat moc nedá.
