Jak propojit kód s designem: UI/UX základy pro vývojáře

Aus MeinWiki
Version vom 21. August 2026, 19:51 Uhr von ClaudeBrassard3 (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „Základním pravidlem je nikdy neskládat SQL dotaz pomocí řetězcové konkatenace. Typická chyba vypadá jako spojení textu s proměnnou, například kdy…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Základním pravidlem je nikdy neskládat SQL dotaz pomocí řetězcové konkatenace. Typická chyba vypadá jako spojení textu s proměnnou, například když do dotazu vložíte uživatelské jméno přímo jako součást příkazu. Pokud uživatel zadá místo jména třeba výraz s apostrofem a podmínkou, může změnit logiku dotazu. Vždy proto používejte připravené dotazy (prepared statements) a parametrizované dotazy. Tyto mechanismy oddělují SQL kód od dat a databáze je pak bere jako hodnoty, nikoli jako příkazy.

Relace a tabulky jsou pro spoustu aplikací pohodlné, ale ne vždy představují optimální řešení. Když narazíte na objemy dat, které přesahují možnosti jednoho serveru, nebo na datový model, který se do tabulek nevejde bez krkolomných konstrukcí, je na místě se porozhlédnout po NoSQL. Nemusí jít hned o kompletní přepis systému; stačí pochopit, kde jsou hranice klasického SQL a co nabízí alternativní přístupy.

Při práci s funkcemi si osvojte volitelné parametry (znak ?) a výchozí hodnoty. Volitelné parametry umožňují zavolat funkci bez daného argumentu, ale uvnitř musíte kontrolovat, zda je hodnota definovaná. Výchozí hodnoty vám ušetří ruční přiřazování undefined. Dávejte si také pozor na typy, které se mění v průběhu času – použijte generické typy, pokud chcete, aby funkce fungovala s libovolným typem při zachování typové bezpečnosti. Například funkce pro zpracování pole by měla být generická, abyste nepřišli o informaci o typu prvků.

Pravidelně testujte aplikaci na zranitelnosti. Používejte automatizované skenery i manuální testy, které zahrnují vkládání speciálních znaků do všech vstupních polí. Zkuste do formulářů zadat obyčejný apostrof a sledujte, zda aplikace vyhodí chybu. Pokud ano, nezanedbávejte to – je to signál, že někde dochází k nedostatečnému ošetření. Dbejte také na to, aby databázový účet používaný aplikací měl pouze nezbytná oprávnění. Oddělte přístup pro čtení, zápis a správu. Tím omezíte škody, pokud k průniku dojde.

Další pastí je implicitní konverze typů. Pokud máte sloupec VARCHAR a porovnáváte ho s číslem, databáze často provede konverzi na každém řádku, což opět znefunkční index. Dbejte na to, aby typy v podmínkách odpovídaly typu sloupce.

Nakonec si osvojte práci s vysvětlením plánu dotazu (EXPLAIN). Tento nástroj vám ukáže, jak databáze dotaz zpracovává, které indexy používá a kde dochází k sekvenčnímu procházení. Než optimalizujete, vždy se podívejte na tento výstup. Často zjistíte, že problém není v dotazu, ale v chybějícím indexu, který se tváří jako existující, ale ve skutečnosti se nepoužívá.

Když se databáze začne zadýchávat, první podezření padá na SQL dotazy. Pomalé dotazy nezpůsobují jen čekání uživatelů, ale i přetížení serveru a zbytečné náklady na infrastrukturu. Než sáhnete po dražším hardwaru, vyplatí se podívat na to, jak jsou dotazy napsané. Často stačí drobná úprava a výsledek se dostaví v řádu sekund.

Indexy: základ, který se vyplácí Nejčastější příčinou pomalých dotazů je chybějící index. Pokud ve WHERE klauzuli filtrujete podle sloupce, který není indexovaný, databáze musí projít celou tabulku. To je u velkých tabulek zničující. Vždy si ověřte, zda index odpovídá skutečným podmínkám. Například dotaz `SELECT * FROM objednavky WHERE zakaznik_id = 42 AND datum >'2024-01-01'` potřebuje složený index na oba sloupce, ne dva samostatné. Složený index funguje efektivně, pokud jsou sloupce v něm seřazené podle toho, jak je používáte v podmínce.

NoSQL není jeden nástroj, ale rodina databází, které se liší datovým modelem. Existují dokumentové (JSON), sloupcové, klíč-hodnota a grafové. Každý typ řeší jiné problémy. Dokumentové databáze se hodí pro obsahově heterogenní záznamy, které byste v SQL řetězili přes deset JOINů. Sloupcové jsou vhodné pro analytiku nad obrovskými tabulkami, kde čtete jen vybrané sloupce. Klíč-hodnota je extrémně rychlá pro jednoduché operace, a grafové databáze zase skvěle modelují vztahy – typicky sociální sítě, doporučovací systémy nebo řízení práv.

Pokud přicházíte z čistého JavaScriptu, první setkání s TypeScriptem může působit jako zbytečná byrokracie. Po pár dnech práce si ale začnete všímat, že mnoho chyb, které jste dříve odhalovali až za běhu, se nyní objeví přímo v editoru. TypeScript není samostatný jazyk, ale nadstavba, která do JavaScriptu přidává statické typování. Jeho hlavní přínos spočívá v tom, že umožňuje lépe popsat tvary dat a vztahy mezi nimi, což oceníte zejména u větších projektů nebo týmové spolupráce.

Základní princip je jednoduchý: definujete typy a TypeScript je kontroluje při kompilaci. Když píšete funkci, která přijímá číslo a vrací řetězec, deklarujete to explicitně. Tím se vyhnete situacím, kdy do funkce omylem předáte objekt a zjistíte to až v produkci. Nejdůležitější je naučit se rozlišovat mezi primitivními typy (string, number, boolean) a složitějšími strukturami, jako jsou rozhraní (interface) nebo typové aliasy. Právě rozhraní se používají k popisu tvaru objektů a usnadňují práci s API odpověďmi či konfiguračními soubory.