Další častý problém je nadměrné používání LIKE s žolíkem na začátku, třeba WHERE jmeno LIKE '%nov%'. Takový dotaz nedokáže využít index a prohledá celou tabulku. Pokud potřebujete hledat text uvnitř řetězce, zvažte plnotextové indexy, které jsou na to stavěné. A když už používáte LIKE, alespoň se vyhněte vedoucímu zástupnému znaku, pokud to jde. Podobně pozor na vnořené subquery, které se vyhodnocují pro každý řádek. Často je lze nahradit JOINem, který je přehlednější a rychlejší.
Nejčastější chybou je sestavování SQL dotazů pomocí prostého zřetězení řetězců. Typický příklad vypadá takto: příkaz, který má ověřit přihlášení, se staví jako text s vloženým uživatelským jménem a heslem. Když útočník zadá do pole pro jméno hodnotu jako ‘ OR ‘1’=‘1, výsledný dotaz se vyhodnotí jako pravdivý a aplikace ho pustí dál, aniž by znala skutečné heslo. Řešení je přitom technicky triviální: používat parametrizované dotazy nebo připravené příkazy (prepared statements). Tyto mechanismy oddělují SQL kód od dat a databáze vstup vždy interpretuje pouze jako hodnotu, ne jako příkaz.
Parametrizace ale není všelék. Druhá častá past se týká dynamických částí SQL – například řazení podle sloupce, které uživatel vybere z rozbalovací nabídky. Tady nelze použít parametr, a tak vývojáři často sáhnou po přímém vložení hodnoty do dotazu. V takovém případě je nutné použít bílou listinu (whitelist): ověřit, že hodnota je přesně jednou z povolených voleb, a teprve poté ji do dotazu zahrnout. Nikdy nepřijímejte název sloupce ani směr řazení z uživatelského vstupu bez předchozí kontroly.
Po dokončení migrace je klíčové spustit sadu regresních testů. Porovnejte počty záznamů, kontrolní součty u vybraných sloupců a výsledky komplexních dotazů. Nezapomeňte na pohledy, triggery a uložené funkce – syntaxe se v PostgreSQL liší, takže je budete muset přepsat. Teprve když jsou testy v pořádku, můžete přepnout aplikaci. Mějte v záloze původní MySQL databázi a plán návratu, pokud by se v produkci objevily problémy. Migrace je úspěšná až ve chvíli, kdy nový systém běží stabilně alespoň týden bez zásadních zásahů.
Kdy je lepší migraci odložit nebo ji provést postupně? Než se pustíte do přenosu stovek gigabajtů, zkontrolujte, jak vaše aplikace používá specifické funkce MySQL. Například FULLTEXT vyhledávání, REPLACE INTO nebo GROUP BY s netriviálními aliasy se v PostgreSQL chovají odlišně. Pokud aplikace používá pokročilé JSON operace, PostgreSQL je na tom výrazně lépe, ale pokud sázíte na MySQL specifickou optimalizaci dotazů, čeká vás ladění výkonu. Doporučuji zvolit postupnou migraci: nejprve přesunete nejsložitější tabulky a ověříte chování v testovacím prostředí. Teprve poté přesouváte zbytek dat. Tím se vyhnete situaci, kdy zjistíte chybu až po přepnutí produkčního provozu.
Rozdeleni casu mezi analyticke faze a implementaci patri k nejcastejsim zdrojum napeti v agilnich tymech. Casto se stava, ze analyza trva prilis dlouho a implementace pak nestiha, nebo naopak zacnete kodit prilis brzy a pozdeji zjistite, ze jste nepochopili zadani. Spolehlivy odhad pritom neziska ani jeden clovek, ani jeden nastroj. Zalezi na tom, jak praci rozlozite v case a jakym zpusobem ji overujete.
Při auditu kódu se zaměřte na místa, kde se kombinují data z více zdrojů – API, soubory, formuláře. SQL injection se neomezuje jen na přihlašovací formuláře. Útočník může vstup poslat i přes hlavičku HTTP, cookie nebo skryté pole. Vždy proto aplikujte stejný princip: žádný vstup není bezpečný, dokud není explicitně validován a zpracován bezpečnou metodou. Pravidelný test aplikace pomocí automatizovaných nástrojů na penetrační testování pomůže odhalit slabá místa dříve, než je objeví někdo jiný. Samotné nástroje ale nejsou náhradou za důkladnou znalost toho, jak útok funguje.
Nezapomínejte také na správné datové typy. Pokud porovnáváte číselný sloupec s řetězcem, databáze musí provést implicitní konverzi, která zablokuje použití indexu. Stejně tak ukládání data jako textu je past, která se dřív nebo později projeví. Držte se typů, které jazyk SQL nabízí, a nenechte se zlákat univerzálním VARCHARem pro všechno. Když už máte dotaz rychlý, zamyslete se nad tím, kolik řádků vrací. Stránkování pomocí LIMIT s velkým OFFSETem je pomalé, protože databáze musí přečíst a zahodit tisíce řádků. Místo toho použijte takzvanou keyset pagination s WHERE id >posledni_id.
Při samotném přenosu dat vyzkoušejte dva přístupy: export a import pomocí pg_dump a také použití ETL nástrojů, které podporují oba systémy. U větších databází se vyplatí rozdělit tabulky na menší celky a přenášet je paralelně. Typickou chybou je přenos všech dat v jednom obřím SQL souboru, což vede k vyčerpání paměti a pádům. Pokud databáze obsahuje binární soubory, In case you liked this short article and viz zde you wish to get details regarding Wiki.Philipphudek.De kindly stop by the web site. ověřte, že je přenesete v režimu BYTEA a že nastavení klienta a serveru je kompatibilní. Jinak se může stát, že se soubory po importu poškodí.
