Vlákno názorů k článku Úvaha ohledně zneužívání LIKE v databázích od Petr - Článek je psán z pohledu kodéra. (To, že...

Článek je psán z pohledu kodéra. (To, že se kodér považuje za mistra světa a všechny ostatní považuje za blbce, to je konstanta. To není potřeba vyzdvihovat, takoví jsou všichni.) Kodér neuvažuje nad potřebami uživatele. Kodér neuvažuje nad ekonomií projektu. Kodér neuvažuje nad skutečným fungováním velké firmy, jak dodavatelské tak zákaznické.

Zazlívat systému, že si v něm uživatel udělá víc, nežli bylo původně navrženo ... je krátkozraké. Uživatel potřebuje víc. Udělat to "správně" znamená: vytvořit požadavek; obhájit business case pro přidělení rozpočtu; vyžádat si od dodavatele cenovou nabídku; znovu obhájit business case; zadat dodavateli; počkat na příští řádné doručení. Tohle trvá asi tak rok. A stojí to hodně peněz.

Pokud uživatel na druhou stranu může "zneužít" systém a udělat si tam, co potřebuje, bývá to výhodnější. Stojí to jen nový hardware, at to jen v nejhorším případě (a navíc nákup hardware bývá snadnější - problém výkonnosti je viditelnější a investice se snadněji schvaluje).

presne z takovych duvodu existuji cela ucetnictvi v excelu. Na prvni pohled je to vyhodnejsi. Z dlouhodobeho hlediska je to nesmysl. Ale mate zcela presne pravdu, ty procedury pro to, aby se to udelalo spravne se tahnou.

Ulohou managementu je hledat cesty, jak to udelat spravne. Tim, ze se orazitkuje pan Stehule jako koder, ktery ma svuj uzky zorny uhel se nic nevyresi. Uvaha pana Stehuleho je tu prave take pro ten management, aby si tito zodpovedni dali 2 a 2 dohromady a zeptali se, jestli je koupe hardware skutecne levnejsi.

Článek není psán z pohledu kodéra, protože návrh vhodných datových struktur (o který jde především) je záležitostí analytickou, nikoliv kodérskou. Wirthovo tvrzení, že program=datové struktury+algoritmy platí stále. Databáze značnou část algoritmů sice řeší za nás ale na správném návrhu datových struktur záleží o to více. Pokud dodržíme doporučení autora na správnou atomizaci a normální formy, pak není problém splnit dostatečně efektivně i takové požadavky zákazníků, se kterými původně počítáno nebylo a navíc lze databázi snadno rozvíjet. (O tom jsem se přesvědčil mnohokrát).

Problém nastává, když zákazník začne do sloupců ukládat jiné informace než tam patří, protože je to "levnější", než jeden sloupec přidat. Takový zákazník JE blbec! Znám případ, kdy do čísla střediska (které nevím proč mělo rozsah až 16 míst) zamontoval zákazník jakýsi typ materiálu a číslo odpovědné osoby a pak si ztěžoval na nečitelnost sestav. Jistě, bylo to levnější, než požádat o přidání dvou slouců ale současně velmi krátkozraké.

A pokud případné změny prosazujete tak, jak píšete, pak musíte být velice těžkopádnou organizací. (Přitom se vsadím, že nakoupit řediteli repre bourák za x melounů je u vás záležitostí pěti minut).

No, pokud zakaznik ke konci vyvoje prijde se zmenou arity vztahu, tak to byva problem :-) Ale jinak souhlasim, kvalitne provedena analyza - dobre zobrazena realita v datovem modelu hodne pomaha.

Takovy postup zmen je bezny v kazde vetsi / velke organizaci. A ono by to asi i jinak neslo. Ani nakup bouraku pro reditele tam neni zalezitosti peti minut :-)

Ja to znam z druhe stranu a pro zmenu obcas dostanu chutovku - nacenit nejakou zmenu, u ktere 80% pracnosti predstavuje analyza problemu, ale bez analyzy neni mozne rict, jak dlouho to bude trvat :-D

To, co píšete, se dá zjednodušeně parafrázovat jako "nejlepší je to od začátku udělat správně". To je sice pravda, leč platónovský ideál. Ve skutečném světě se to skoro určitě správně neudělá.

Trochu mě zde napadá ono cimrmanovské "... ale chodili mu tam lidi!". Největším nepřítelem toho tak úžasně navrženého IT systému je uživatel, který ho chce používat podle sebe a ne podle idealizovaných konstrukcí analytika.

No jo, kdyz uzivatel [skoro] nikdy nevi, co vlastne chce, ale neda pokoj, dokud to nedostane. A nejzavaznejsi pripominky zacina mit ve fazi prechodu na novy SW ...

Právě analytik je tu od toho, aby domýšlel návrhy zadavatele do důsledku a projekt "odidealizoval". Z mnoha spoluprací se zadavatelem mám několik základních zkušeností. Za prvé: Zadavatel je líný přemýšlet. (Musíte tedy přemýšlet za něho). Za druhé: Zadavatel vám neřekne nic, na co se přímo nezeptáte. (Musíte tedy pátrat, na co se ptát). Za třetí: Nikdy nevěřte zadavateli, tvrdí-li, že něco se nemůže změnit. (Obvykle se to změní ihned po nasazení do rutinního provozu). A konečně za čtvrté: O potřebných datech a funkcích vědí nejvíce ti, kteří s nimi denně pracují. Komunikovat pouze s jejich nadřízenými nestačí. Má-li program práci ušetřit a ne přidat, musíte sejít "do suterénu".

Největší naději na úspěch má projekt, který je nasazován do provozu už v průběhu svého vývoje a průběžně kontrolován uživatelem. Pak je tu jistá naděje, že skutečně bude vykonávat to, co uživatel potřebuje. Časté tvrzení, že programátor se pohybuje v jakýchsi andělských svérách a na běžného uživatele kašle, je blud. Nemůže ovšem vyhovět takovým přáním, které si protiřečí.

Zásady správného datového návrhu, o kterých se autor článku zmiňuje, byly vymyšleny právě proto, aby se projekt mohl snadno obohacovat, rozvíjet a měnit. Vycházel z letitých zkušeností, osvědčil se a jeho autoři nebyli žádní hlupáci. Je smutné, že se mu vysmívají právě ti, kteří se mohou nejvíce přiučit.